On 1/30/05 12:14 AM, Bryan Pietrzak didst favor us with:
>
> On Jan 29, 2005, at 7:04 PM, Laurence Harris wrote:
>
>> Because you don't understand the CarbonEvent system and standard
>> handler.
>> Give them commands, watch for the commands in a kEventCommandProcess
>> handler, and forget about the rest. That's the Carbon "How easy can
>> this
>> get?" way of doing things.
>>
>
> I understand carbon events.
>
> I only use commands for menu items. All my control handling goes
> through control hit events. There are a few reasons for doing this, not
> the least of which was retrofitting my existing code which used this
> approach of event handling already.
I understand this is an option, and I can even see how it would emulate the
Dialog Manager approach to responding to interactions with window elements
nicely. But I still see some drawbacks. I don't want a kEventControlHit
handler called every time a user interacts with something in a window
(including the content view). On the rare occasions I do want a
kEventControlHit handler called, I install it on the relevant controls, not
the window. Personally, I prefer to minimize the paths in my code. If some
actions are handled by kEventCommandProcess handlers and others are handled
by kEventControlHit handlers, that seems inconsistent to me, and on those
occasions where a control in a window does the same thing as a menu command,
it makes even less sense to me to handle them through different mechanisms.
Using commands for some buttons in a window and not others also seems
inconsistent. (FWIW, my preference for consistency is not just a personal
preference. I find it easier to maintain code that channels actions through
the same mechanism instead of through multiple mechanisms.)
However, all that said I understand we have different code bases and issues
with which we need to deal, and some people may have legitimate reasons for
using one approach over the other. The one thing we've learned here is that
if you're using a kEventControlHit handler and you install in on the window,
check the signature *and* id before handling the event. ;-) It's an issue
that doesn't come up if you use commands or you install the kEventControlHit
handler on the controls themselves.
Larry
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Carbon-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/carbon-dev/email@hidden
This email sent to email@hidden
