NSWindow class that allocs its own controller?
NSWindow class that allocs its own controller?
- Subject: NSWindow class that allocs its own controller?
- From: daniel <email@hidden>
- Date: Wed, 6 Apr 2005 11:19:34 -0700
Should a class that is typically instantiated via a controller, e.g. an
NSWindow subclass that is managed by an NSWindowController, be made
capable of "instantiating its own controller"?
I am faced with this question in my attempt to add AppleScript support
for a controller-managed window class in my application. Cocoa
Scripting likes to instantiate objects directly by class name. In my
case, it's an NSWindow subclass that I ultimately want to expose to
AppleScript, but it's instantiated typically via an NSWindowController.
Let's say FunWindowController manages a FunWindow whose interface is
contained in FunWindow.nib.
Ordinarily, to instantiate a FunWindow from code, I would allocate and
initialize a FunWindowController, which would in turn
"initWithWindowNibName" for FunWindow.nib.
To get "easy AppleScript support," I can define a FunWindow class in my
scripting definition and define it as a subclass of "window", with a
class name of "FunWindow." The obvious problem here is that FunWindow
is incapable of instantiating itself.
So, I could add an "init" method to my FunWindow that releases self and
in its place returns a freshly created FunWindowController's window.
Yuck! I would probably also have to detect a cycle since init would
probably re-enter as soon as FunWindowController created its window.
How do I do this correctly? I asked about this on
AppleScript-Implementors but twice received a resounding silence. Am I
missing something big here? I see a big disconnect between the
AppleScript object model and the Cocoa tendency to rely on "helper
objects." Hopefully somebody smarter than me (and who doesn't read
Applescript-Implementors) has dealt with this and can offer some
advice.
Thanks!
Daniel
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden