Re: Okay I have those pieces... now where's the glue?

FROM : Vincent E.
DATE : Tue May 27 22:59:03 2008

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_removed>)

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/<email_removed>

This email sent to <email_removed>