Hi,
yes, it might be something like this. Unfortunatly I had a fatal hard
disk crash today so it will take some time until I get to the point
again where I can try out what you suggested. To test that and to get
more into this topic I think I will build a sample setup to get more
into this topic. I will come back later then.
Coming from Windows and Linux programming land into Mac is harder than I
thought it would be...
Regards
Clemens
Alexander Spohr schrieb:
Sounds like your context is not set.
How do you call the „drawing code“ in B?
Possible solution:
Make a subclass of NSOpenGLView that overrides drawRect: in A
Give it a delegate and make some instance from B the delegate.
Trigger [NSOpenGLViewSubclass display]
NSOpenGLViewSubclass should then tell the delegate in B to draw.
Done.
atze
ps. set NSOpenGLViewSubclass in the nib to be your view :)
Am 26.03.2009 um 18:07 schrieb Clemens Arth:
Hi,
I got a question to a rather weird problem I came across. We are
developing an entire software suite in a set of shared libraries
which are linked together with some type of Bootloader to an
application. One library contains stuff related to IO, one contains
rendering stuff and so on. I have to note here that this works well
on Linux and Windows, and now I've tried to port that to OSX. I've
tried to do achieve the same behaviour as on Linux and on Windows as
follows:
In the IO library I created an interface for opening a nib file
called WinControl which contains the outlets. The nib file itself
only contains a NSOpenGLView which is embedded in an NSWindow. In
principle this works quite well if I set the File Owner of the nib
file to be of the class WinControl and do something like
/* snip */
WinControl * control = [[WinControl alloc] init];
[NSBundle loadNibNamed:@"MyNibFile" owner:control];
/* snip */
Note that this loading-of-nibs stuff is all contained in library A,
and it seems that all drawing code also contained in library A works
as expected.
Now, in our case library B contains the real important rendering
stuff, also including code to compile shaders. The real problem I
have here is:
If I create an application linking to A and B, the code in library B
is not able to make use of the OpenGL context which is obviously
created through library A (simply by loading a nib file with an
embedded NSOpenGLView). After trying a lot of different things I'm
pretty sure that this has to do with the question of "owning" the
context. If I call drawing code contained in A from a function
contained in B everything works, but if I include the drawing code
directly in B it does not work (crashing with EXC_BAD_ACCESS).
Does someone have an idea what I can do about that? I'm a
more-or-less beginner in Cocoa programming, and I'd really appreciate
if someone could explain to me how to circumvent this problem without
changing the overall structure of the software suite (i.e. the
modularization into separate libraries for different tasks).
Regards
Clemens
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/atze%40freeport.de
This email sent to a...@freeport.de
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
