Mailing Lists: Apple Mailing Lists
Image of Mac OS face in stamp
 
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Changing the signature of a window


On Jan 29, 2005, at 10:19 PM, Laurence Harris wrote:

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.

Well said. I think this description was much better than just saying that I don't
understand Carbon Events. An event handler checking for a kEventControlHit
is roughly the same amount of code as a handler looking for a
KEventCommandProcess. There are some places that I require the use of
kEventControlHit and from a consistency standpoint I started using it other
places as well. Though in those case where I really require it I believe I'm
connecting the handler to the control.

In cases where a button on a window is the same command as a menu option
I am using the kEventCommandProcess.

Not checking the signature when using kEventControlHit clearly was a design
flaw on my part. I guess if we wanted to make a handler really robust we
could check to make sure the event class and kind are correct as well as the
signature & ID and the Command. That's a bit of an overkill if we have a
single event attached to a single control but would be necessary if we have
multiple event class & kinds attached to a window that has multiple controls.

I think that your right that kEventCommandProcess being a bit more high level
makes sense to use when kEventControlHit is not really required.

Mike

_______________________________________________
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
References: 
 >Re: Changing the signature of a window (From: Laurence Harris <email@hidden>)



Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2007 Apple Inc. All rights reserved.