On 08/09/2013 10:02 AM, Gregory Casamento wrote: > I'm not certain. I'm currently trying to build Darling with the > latest GNUstep in order to test. > > My current hypothesis is that there have been changes in how some > classes are archived in later nib versions and the current code isn't > reading some properties correctly. > > Gregory Casamento [email protected] Open Logic Corporation, > President/CEO GNUstep Lead Developer
No, that NIB works too, as long as I use a native build of that app. It just doesn't have a menubar - so there is a bug in the NIB loader in this regard. The drawing, however, is a different story. [NSCustomView nibInstantiate] correctly creates a MyCustomView instance. In the native binary, the initWithFrame: call ends up in MyCustomView. But under Darling, it ends up in NSView. This seems to be the reason why nothing is drawn - calls are not delivered to MyCustomView when they're made from gnustep-gui. When I add: id obj = [c alloc]; [obj initWithFrame: 0]; directly into my ObjC loader (where c is class MyCustomView), it works. Is it possible that there are two different selectors with the same name in the system, one invokes the superclass' implementation and the other one invokes the the subclass' implementation? -- Luboš Doležel _______________________________________________ Gnustep-dev mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnustep-dev
