On Fri, 2004-04-02 at 16:08, David Webb wrote:
> What device are you doing this on? For my stuff, it doesn't work well on
> POSE at all - its very jumpy, but works fine on any device from Palm V
> through Tungsten C. Here's a snipet of my code - it uses a gadget control
> as the input area. I do nothing special in the app event loop. AddPoint()
> just records the points into an array to be saved at the end.
>
> objIndex = FrmGetObjectIndex (frmP, GadgetID);
> FrmGetObjectBounds (frmP, objIndex, &r);
> do {
> PenGetPoint (&x, &y, &penDown);
>
> // Check array bounds
> if (ptCnt1 >= (MAX_STROKES - 10)
> break;
>
> if (y != y1 || x != x1) { // Throw away all of the repeat events with
> the same coordinates
> // If all points are in the bounds of the gadget and this isn't the
> first point
> if (RctPtInRectangle (x, y, &r) && RctPtInRectangle (x1, y1, &r) &&
> x1 && y1) {
> WinDrawLine (x, y, x1, y1); // Draw a line on the Palm from the
> previous pen point to the new point
> AddPoint (x - x1, y - y1, false);
> } else if (RctPtInRectangle (x, y, &r)) { // add a starter point
> AddPoint (x - r.topLeft.x, y - r.topLeft.y, true);
> }
> x1 = x;
> y1 = y;
> }
> } while (penDown);
This is, in effect, the heart of what I was doing.
The problem that this code above has, though, is what happens when an event happens
while
you're drawing? Above, the answer is *nothing*, because no events are handled at all.
Now, this might be okay, and it might not. For example, if the event is a low power
report,
at first blush one might think it's okay not to respond to the event until the user is
done
drawing, because how long is an individual pen stroke, right?
Well, what if they've set the palm on a desk, and then laid a book or something on top
which
just happened to register as a pen press? Then your code would go into a tight loop.
If
the user got busy with something else and doesn't get back to their palm for a while,
they'd
find that the Palm is now dead, as the battery has been emptied.
It's an interesting question what would happen at this point...since as I understand
it the
palm sends itself an event to 'turn off'. If this event is never seen, does the Palm
force
a shutdown at a certain battery level, no matter what?
This is a hypothetical reason why not to always ignore events. I'm sure there are
plenty of
real reasons right now why you wouldn't want to ignore events, but what about in the
future?
As devices change and more and more things are added to them (bluetooth, 802.11x,
etc), we
will have more and more reasons why we cannot ignore events.
It just doesn't seem like defensive programming to me.
-Ken
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/support/forums/
