Thanks... I think I'm with you... kinda of.
So, let's say for the sake of argument I have some NSView subclass
implemented in Java: MyView.
In interface builder I drag in a custom view and I set its type to
MyView by typing in the name of this class, which doesn't exist as an
Objective C class.
When I load that nib file, I'm going to get an error message on the
console complaining correctly that MyView doesn't exist.
What I was looking for was a hook from the runtime so I could step in
and define some kind of forwarding proxy, which would be the MyView
class as far as the objective C runtime was involved, but would
"delegate" all functionality to the actual Java class.
objc_setClassHandler would have provided just such a hook. (assuming
the name is sufficient to know which class to load, which it usually
but not always would be).
Are you proposing instead that the programmer, knowing MyView needs to
exist, calls objc_allocateClassPair, class_addMethod and
objc_registerClassPair in advance of loading the nib to ensure the
classes exist?
That's OK but its a mite clunky. Seems like with most things in obj-c
you get notified before a failure occurs so you can step in (e.g.
class doesn't respond to message). And indeed this used to exist for
undefined classes, but they removed it :(
Unless there's an API to examine a NIB file and see what classes are
required to load it? Can NSBundle do that?
AndyT
On Jan 31, 2009, at 5:51 PM, Michael Ash wrote:
On Sat, Jan 31, 2009 at 3:36 PM, Andrew Thompson <lordpi...@mac.com>
wrote:
Hi all,
I was looking for a way to define Objective-C classes at runtime...
specifically to be able to supply class definitions when a Nib file
is
loaded. This search soon led me to objc_setClassHandler, but
that's listed
as deprecated without replacement here:
http://developer.apple.com/documentation/Cocoa/Reference/ObjCRuntimeRef/Articles/ocr10_5delta.html
What's the story here? Is there a new, preferred way to do this?
What are
the Ruby etc. bridges doing?
The bridges don't need this functionality, as they can build the
bridging classes as they are created, rather than doing lazy loading.
If you can do that as well, that would seem to be an obvious approach.
The contents of a nib file shouldn't be a mystery, but should be known
ahead of time, so you ought to be able to create all of your classes
before you load the nib.
Mike
_______________________________________________
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/lordpixel%40mac.com
This email sent to lordpi...@mac.com
AndyT (lordpixel - the cat who walks through walls)
A little bigger on the inside
(see you later space cowboy, you can't take the sky from me)
_______________________________________________
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
