On Tue, 6 Apr 1999, Bob Ebert wrote:
> At 5:53 PM -0800 4/5/99, Kenneth Albanowski wrote:
> >On Mon, 5 Apr 1999, Bob Ebert wrote:
> >
> >> I like the idea of having a callback mechanism. Probably we could make do
> >> with just one call-back hook that gets called once before any form stuff
> >> was drawn but after the erase, once for each gadget, and once after all the
> >> form stuff was drawn.
> >
> >We've done without callbacks so far (except for the sort functions and the
> >form handler functions),
>
> ... and table drawing functions, and table loading functions, and list
> loading functions ... There is precedence. :)
OK, so I was off by three. :-)
> >and I think I'd like to see it stay that way. But
> >maybe we could get a new set of events for gadgets, or a new event filter
> >function that makes it easy to generate events for gadgets.
>
> So you don't think having the event handler be re-entrant would be a
> problem? (Your form event handler calls FrmDrawForm, which would then
> call-back into the event handler to handle drawing the gadget. It's either
> that or gadget drawing is deferred until the next pass of the event loop,
> which doesn't solve this problem.)
No, I didn't mean generate events that go back into the event loop. Rather
use an event processor, rather like FrmDispatchEvent(), that takes care of
synthesizing whatever events are needed, and passes them to the specified
callback, _synchronously_, just like FrmDispatchEvent().
Actually, Palm needn't actually do anything, given this technique. It
would be possible for anyone to write such a handler that looks for some
frm and pen events, and steps through the loaded form data to synthesize
gadget events. (If you don't mind stepping through a form structure...)
The idea is to not waste the time on computing gadget events if there
aren't any...
> Anyway, I'm not sure if all those events are completely necessary. Most of
> that stuff can be handled through existing form events. Drawing at the
> right time is a significant problem, and I think hit testing, visibility,
> etc. could use a little more support, but that's about all I was
> envisioning.
>
> For the list in general: (I don't want to open up a huge can of worms
> here, so try to be conservative) What's in the way of effectively using
> gadgets right now?
They don't gain you anything in relation to on-screen stuff. They're
useful for Datebook, but it uses a gadget to pass the alarm data around,
not to do anything on the screen. If I want to synthesize a button, I'll
need to watch for penDown and see if it intersects a particular rectangle,
and then do my own recursive loop to do highlight and release tracking.
The _only_ benefit to using a gadget in this context is the ability to
specify the desired rectangle in a resource.
Likewise, for anything else where I want a custom or synthesized widget,
there is simply no benefit to using a gadget. If I want to draw something,
then I'll need to watch for frmDrawForm and frmUpdateForm, regardless of
whether a gadget is used, etc.
--
Kenneth Albanowski ([EMAIL PROTECTED], CIS: 70705,126)
