 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Mac Forum / Programming / CodeWarrior / December 2003PPx: Broadcast/Listen replacement
I have been using PowerPlant for several years. In my PP apps, except for controls, Broadcast/Listen functionality is used primarily to pass information from one part of a program to another via the associated void pointer. This enables me to maximize modularity. That is, a Broadcaster can send a message asking for some specific data without having to know which object supplied the answer. Typically, the void pointer is filled in, by the asker, with the address of a struct which both askers (often more than one) and replier know how to typecast. Thus, none of my component-object modules contain headers for any higher-level, enclosing objects. [They have no need to know.] The PPx documentation instructs one to replace Broadcast/Listen with Carbon Events but, as far as I can tell, standard Carbon Events are strictly one-way communication with no (synchronous) reply capability. Am I correct in assuming that I must create a custom event, followed by SetEventParameter, to reproduce the capability described above? or is there a standard event with an unused void pointer in it? Can every custom event have a parameter? Would the asker have to know the target of its query (where to post the event) in case the replier is not in the containment hierarchy? or must a higher-level object tell the asker (e.g., in its ctor) where to send such a query (as in AddListener)? TIA. -- Mike McLaughlin > The PPx documentation instructs one to replace Broadcast/Listen with > Carbon Events but, as far as I can tell, standard Carbon Events are [quoted text clipped - 5 lines] > > Can every custom event have a parameter? You can add custom parameters to any Carbon Event, just make up your own EventParamName (a four-character code). The function in SysEventParam.h will help you get/set parameters. You are not limited to void* values. You can use any data type. > Would the asker have to know the target of its query (where to post the > event) in case the replier is not in the containment hierarchy? or must > a higher-level object tell the asker (e.g., in its ctor) where to send > such a query (as in AddListener)? If I understand your question, you can do it either way. You can either post or send a Carbon Event. Posting an event puts it into the event queue for later delivery. A posted event may be directed to a specific target, or to a default target (which is usually the user focus target at the time the event is handled). Sending an event is synchronous, similar to how Broadcast/Listen works. You must send an event to a specific target. The target can fill in data by adding a custom parameter to the event and the caller can then extract the parameter after the event handler returns. PPx doesn't have a Broadcaster class, but you could make one that has similar semantics to LBroadcaster. Such a class would have a list of EventTargets. Then, any subclass of EventTarget would a potential Listener. -- Greg > PPx doesn't have a Broadcaster class, but you could make one that has > similar semantics to LBroadcaster. Such a class would have a list of > EventTargets. Then, any subclass of EventTarget would a potential > Listener. I seem to remember doing some profiling and noting that even LBroadcaster was taking measurable time. I worry that having to construct (and release) Carbon Events is going to be a performance hit in some situations. Is there a reason why the lightweight approach was dropped?  SignatureDavid Dunham A Sharp david@SPAM_B_GONE.a-sharp.com http://www.pensee.com/dunham/ "I say we should listen to the customers and give them what they want." "What they want is better products for free." --Scott Adams > I seem to remember doing some profiling and noting that even > LBroadcaster was taking measurable time. I worry that having to > construct (and release) Carbon Events is going to be a performance hit > in some situations. Is there a reason why the lightweight approach was > dropped? By the lightweight approach, I assume you mean LBroadcaster's way of doing a direct function call rather than sending a Carbon Event. With Carbon Events, the system handles a lot of the work. You can add custom paramters and queue events (even across threads). Letting the system do the work means less code for PPx, which is a good thing. Whether the overhead of Carbon Events is significant will depend on your application. The OS itself sends a lot of events, so I think Apple is doing what they can to make it fast. As with most performance issues, you need to profile your program to find the bottlenecks and determine if a more lightweight message sending scheme would help. But for simple messaging between objects for things like responding to user actions in a control, I think Carbon Events work nicely. -- Greg > By the lightweight approach, I assume you mean LBroadcaster's way of > doing a direct function call rather than sending a Carbon Event. I'm more concerned about the fact that you have to allocate and deallocate the Carbon Event; memory stuff (since it's got to be thread-safe) is probably slower than CE dispatching. > But for simple messaging between objects for things like responding to > user actions in a control, I think Carbon Events work nicely. I'm sure you're right for something like a dialog. But I'm not sure how well it scales (e.g. if you had something like a spreadsheet, where cell dependencies were implemented with this sort of mechanism). On the other hand, I guess you only have to create and destroy the Carbon Event once; sending or posting just refcounts. SignatureDavid Dunham A Sharp david@SPAM_B_GONE.a-sharp.com http://www.pensee.com/dunham/ "I say we should listen to the customers and give them what they want." "What they want is better products for free." --Scott Adams Try looking at the boost signal for a replacement... Much nicer.. > I have been using PowerPlant for several years. In my PP apps, except > for controls, Broadcast/Listen functionality is used primarily to pass [quoted text clipped - 26 lines] > -- > Mike McLaughlin |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.