FROM : Nathan
DATE : Tue May 27 23:16:21 2008
I'm not joining your discussion here, just giving you a nice linkie.
Cocoalab.com has done a great job with their tutorial, becomeanxcoder
or something like that. It assumes you have no knowledge of C, and it
has put me into a great position, I'm able to use other tutorials now.
On May 27, 2008, at 5:09 PM, Erik Buck 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?
>
> 1) A can have an instance variable that points to B.
> 2) B can have an instance variable that points to A.
> 3) A can be the delegate of B. (specialization of 2)
> 4) B can send notifications that A observes.
> 5) B can send messages up the responder chain. If A is in the
> responder chain it will get a chance to respond to the message
> unless some object earlier in the chain consumes the message.
> 6) B can access A through a global variable...perhaps [[NSApp
> delegate] doSomething];
> 7) A can observe properties of B. (not recommended for newbies)
>
> Which technique you choose depends on the problem you are trying to
> solve and the design of your application. All of these techniques
> are common Cocoa design patterns. In a total vacuum of information,
> I bet you want option 4.
>
>> But as only Controller A knows about B and not the other way round
>> this seems not possible.
>
> This seems like a good scenario to use notifications or the
> responder chain.
>
>> I have created a NSPopupButton in IB. I also created some MenuItems
>> for it in IB.
>> How can I identify the current menu item?
>
> Don't store application state information in user interfaces.
> Have each menu item send a different action to your controller and
> have the controller update the model accordingly. Don't poll the
> state of a user interface item.
>
> Alternately, have all of the menu items send the same action and
> use the menu item's tag or representedObject or even its index to
> determine which menu item was selected. Then have the controller
> update the model accordingly. Don't poll the state of a user
> interface item.
>
>> Ps: Is there any generic(!) open source app that you would recommend
>> me to study to learn more about how to structure an app at best?
>
> Many Cocoa developers learned via the Sketch sample application or
> its predecessor. There are many good Cocoa examples on your hard
> disk and at developer.apple.com. There are also opensource Cocoa
> projects that you can find with Google.
>
> _______________________________________________
>
> 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/lipton_lover
> %40mac.com
>
> This email sent to <email_removed>
DATE : Tue May 27 23:16:21 2008
I'm not joining your discussion here, just giving you a nice linkie.
Cocoalab.com has done a great job with their tutorial, becomeanxcoder
or something like that. It assumes you have no knowledge of C, and it
has put me into a great position, I'm able to use other tutorials now.
On May 27, 2008, at 5:09 PM, Erik Buck 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?
>
> 1) A can have an instance variable that points to B.
> 2) B can have an instance variable that points to A.
> 3) A can be the delegate of B. (specialization of 2)
> 4) B can send notifications that A observes.
> 5) B can send messages up the responder chain. If A is in the
> responder chain it will get a chance to respond to the message
> unless some object earlier in the chain consumes the message.
> 6) B can access A through a global variable...perhaps [[NSApp
> delegate] doSomething];
> 7) A can observe properties of B. (not recommended for newbies)
>
> Which technique you choose depends on the problem you are trying to
> solve and the design of your application. All of these techniques
> are common Cocoa design patterns. In a total vacuum of information,
> I bet you want option 4.
>
>> But as only Controller A knows about B and not the other way round
>> this seems not possible.
>
> This seems like a good scenario to use notifications or the
> responder chain.
>
>> I have created a NSPopupButton in IB. I also created some MenuItems
>> for it in IB.
>> How can I identify the current menu item?
>
> Don't store application state information in user interfaces.
> Have each menu item send a different action to your controller and
> have the controller update the model accordingly. Don't poll the
> state of a user interface item.
>
> Alternately, have all of the menu items send the same action and
> use the menu item's tag or representedObject or even its index to
> determine which menu item was selected. Then have the controller
> update the model accordingly. Don't poll the state of a user
> interface item.
>
>> Ps: Is there any generic(!) open source app that you would recommend
>> me to study to learn more about how to structure an app at best?
>
> Many Cocoa developers learned via the Sketch sample application or
> its predecessor. There are many good Cocoa examples on your hard
> disk and at developer.apple.com. There are also opensource Cocoa
> projects that you can find with Google.
>
> _______________________________________________
>
> 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/lipton_lover
> %40mac.com
>
> This email sent to <email_removed>
| Related mails | Author | Date |
|---|---|---|
| Erik Buck | May 27, 23:09 | |
| Nathan | May 27, 23:16 |






Cocoa mail archive

