Re: Okay I have those pieces… now where's the glue?
Re: Okay I have those pieces… now where's the glue?
- Subject: Re: Okay I have those pieces… now where's the glue?
- From: "Vincent E." <email@hidden>
- Date: Tue, 27 May 2008 22:59:03 +0200
On May 27, 2008, at 10:25 PM, Wim Lewis wrote:
Have you looked at the examples that get installed with the
developer tools? In particular, under the "AppKit" subdirectory
there's the source to TextEdit and a simple drawing application
named Sketch, both of which are pretty good examples of small but
complete applications.
Thanks, I'll take a look at those.
On May 27, 2008, at 10:21 PM, Jens Alfke wrote:
On 27 May '08, at 1:04 PM, Satsumac wrote:
How do I allow controller A to send commands to controller B and
vice versa?
If controller A initialized controller B, then A knew about B, but
what about the other way round?
I seem to remember this exact question coming up a few days ago...
I joined this group yesterday, so this might be. Didn't find it in
CocoaBuilder, though.
If both are in the nib, add outlets to wire them to each other.
If A initializes B, then have A pass itself as a parameter to the
initializer, or set itself as a property on B (like a delegate), or
have A listen for notifications posted by B, or observe property
changes.
Passing a pointer to itself with something like "initWithCallback:
(id)callback" was what came to my mind. At least I wan't that far
away. :)
Controller A is my AppController and does all the general GUI stuff
like opening windows, swapping subviews, etc.
Controller B is the class that performs the actual task. Controller
B shall not have an instance in the nib. It gets its outlets by
being passes to the nib as File's Owner via "setDelegate".
It sounds like you have a multiple-nib application, where controller
B runs a window, and multiple instances can be opened.
Not quite, but almost. It's actually one window with exchanging window
subviews.
Each subview holds the options for a particular task, which is
connected to a particular controller,
which does both: performinf the actual task and answering GUI actions
from the view.
But it does not get instanciated multiple times. Every task exists
just once. (as a "mode" or "tool" of my app)
But there are several "tools" with each having an own view and
controller.
The AppController is for all other actions of the app which are not
tool-specific,
like resizing the main window to fit the size of tool xyz, aswell as
exchanging the window's subview.
I also created a "master tool-class" which all tools themselve are
subclasses of.
This allows me to define methods to be available to all tools.
In that case, the app controller A shouldn't be involved in the
details of the windows maintained by B. It should instantiate B when
told to open a new window, and then leave B to manage the window.
So if—say—a tools task fails I should rather send some
"toolsTaskDidFail:" notification which the AppController then receives
and answers?
I then have a Button for invoking an action. NSButton sends an
action to Controller A which then does some GUI stuff and then
tells Controller B to perform its task.
Where is the button? If it's in the window managed by controller B,
then it should be connected to controller B instead.
The Button is outside of the tool's view in the main window. The
button invoke's the currently active tool's executeTask method.
During the execution of this task Controller B might notice that
something went horribly wrong and Controller A is highly needed to
update the GUI.
Again, A probably shouldn't be involved in B's GUI. You can use the -
presentError: method to send the error up the responder chain, and
have the application handle it.
Okay, I'll look that up. (kind of like my "toolsTaskDidFail:"
approach, right?)
You might want to look through some of the sample apps that use
documents and/or multiple windows, to see how they factor their code.
I'll do that. Even though my app is not supposed to be document-based.
—Jens
Cheers,
Vincent_______________________________________________
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