On Jan 30, 2005, at 12:19 AM, Laurence Harris wrote:
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.
To be honest, the overhead added is so minimal it wasn't even a concern
of mine (that it was installed at the window level).
Personally, I prefer to minimize the paths in my code.
Not me, I want things to be as convoluted as possible ;)
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.)
I only use commands for menu items. I've had very few situations where
a control in a window resulted in the same code as a menu item being
called. But that's mostly due to the nature of those apps.
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.
Yeah, a large part of my usage on control hit events is simply an issue
of it easily mapping to my old homegrown "framework" (I use that term
loosely). When I originally carbonized it a few years ago, the move to
control hit events was a *very* natural fit. There were so many other
things to do, so many other places where re-engineering would add value
that I didn't see a need to do that here.
I've been moving some newer stuff over to commands, and this discussion
has encouraged me maybe to be a bit more aggressive about doing that,
but really, I was just commenting because you seemed to assume that
someone using control hit events instead of commands didn't understand
carbon events. ;)
Bryan
_______________________________________________
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
