Re: Unknown class ‘MyCustomView', using 'NSView' instead
Re: Unknown class ‘MyCustomView', using 'NSView' instead
- Subject: Re: Unknown class ‘MyCustomView', using 'NSView' instead
- From: Roland King <email@hidden>
- Date: Sun, 22 Feb 2015 20:22:54 +0800
> On 22 Feb 2015, at 19:17, Erwin Namal <email@hidden> wrote:
>
> Thank you for your reply.
> I already use both Other linker flags “-ObjC” and “-all_load” in the library, in its bundle target (though it is useless I think) and in the application including the library and the bundle with the nib.
> Then, I load the nib in the bundle by using :
>
>> initWithNibName:nibName bundle:libraryBundle
>
> The other linker flags did solve the issue of categories in the library not visible in the application.
> The thing I don’t understand is that I get the warning, but my application works fine. It shouldn’t if NSView was indeed used instead of MyCustomView.
>
> Where do you put your linkerhack class ? In the library or in the app ?
>
> Thanks for your help
> – E
>
I put it in the app.
Indeed if an NSView was actually used instead of a custom view, if the custom view really does something custom, then you should have problems because you've instantiated entirely the wrong class. Have you stuck a breakpoint on the init methods to see when they are being called?
Given you have a library, a bundle and an app, I have no idea what visibility a class needs to have to be found when you load the NIB, I'd think it was app context.
If you're using -ObcC and -all_load then you're effectively just doing much the same as including all the source files in your library in every app you build, which makes the use of the static library and the work done in refactoring it out somewhat less useful than it might be. And I'm pretty sure Apple fixed the bug in the linker introduced around the time of 64 bit builds so that all_load is really not needed any more, but StackOverflow is never going to let anyone forget those flags.
I stopped using categories on any objects which go in static libraries long ago because I feel they just aren't really compatible.
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden