A followup to Pete Angiuoli's question on gadgets:
I think I understand that if I put an input field on a form, that the form
handler does not "see" low-level events such as pen up/down. Through some
magic, they get routed directly to the input field, and handled by code in
the Palm OS handler for input fields. There is no special routing that the
form handler has to do to say to the input field that a pen was tapped.
I think I also understand that if I write a gadget, that it does not
magically receive events that happen within its client area rectangle, it
is the responsibility of the parent form to figure out that a pen down that
happened at coordinates 100,50 should be handled by the gadget at that
location. So I wind up with code in my form handler that looks like this:
-Get a pen event
-Determine the location of the pen tap
-Figure out if there is a custom gadget that is "underneath" that x/y location
-Hand the event to some piece of code that is responsible for handling a
pendown in the context of the gadget (ex. change the cursor position).
You can see where this becomes unwieldy if, say, I've written a "super
input field" gadget, and I've got 16 of them on my form.
So my question is, how is it that pen events and such are automatically
routed to the "built-in" UI elements? Is there a way for my own "custom
gadgets" to participate in this mechanism, such that my parent form handler
logic does not have to manually route these events? Under windows, because
of the parent-child relationship of windows, this is automatically handled
by the UI element that "has the focus".
Assuming I'm not just hopelessly confused, any insight on this would be
helpful to us.
Thanks!
Glenn Bachmann
Bachmann Software and Services, LLC
http://www.bachmannsoftware.com
Software for Handheld & Wireless Computing, Windows and the Internet
Authors of "Palm Programming", published by Macmillan/Sams, and home of
Bachmann Print Manager, the only graphical printing solution for the Palm
Computing Platform
