I wrote...
>> EvtGetPen can only exacerbate the problem. It passes back the last-known pen
>> position, so if there are rapid taps, it could miss some of the positions.
>>
>> For example:
>>
>> event 1: pen down
>> event 2: pen up
>>
>> Fitaly gets event 1, calls EvtGetPen and gets the proper pen-down coordinate
>>
>> event 3: pen down somewhere else
>>
>> Fitaly gets event 2, calls EvtGetPen bug gets event 3's position rather than
>> event 2's position.
Daniel McCarty replied...
> But if you're handling penDown/penUp's in your own event loop
>then you should never get a penUp event. You should only be
>watching for penDown events. Or am I missing something simple?
> In your example, if you used an EvtGetPen loop, event #2 would
>never even be posted, and that would simplify things somewhat. So
>event #3, a penDown, _should_ then get detected reliably.
Then David Fedor continued...
>That's in fact the generally recommended way to do things. When you get a
>penDown in a control of your creation, sit in a loop doing animation (as
>necessary) until EvtGetPen says the user released the pen.
>
>(I don't know whether or not there's a bug in the pen driver, or the other
>things covered in this thread, but that's my two cents on this issue.)
And I continue my argument...
It may be the recommended way, but I don't think it's right. It makes the
assumption that Fitaly will get every penDown event in real-time; that there
will never be a penDown/penUp/penDown during a time that Fitaly hasn't got
control.
Or in my event-chronology examples...
Fitaly calls EvtGetEvent, that event isn't handled by Fitaly, so it's passed on
to the application (for example a keyboard character being inserted into a
field, or a shortcut expansion perhaps...)
The application (or Palm OS or whatever) takes some time - perhaps that
character triggered a word-wrap or something
User taps on several keys rapidly... (say, penDown/penUp/penDown/penUp for two
"keystrokes")
Now the application calls EvtGetEvent again, and Fitaly gains control again.
(Fitaly traps EvtGetEvent) Fitaly calls the "real" EvtGetEvent and gets the
first penDown (which happens to have the right pen-coordinates)
What happens currently is that Fitaly will then call the real EvtGetEvent and
get the following penUp which has the wrong coordinates.
What you're proposing is that I would instead call EvtGetPen -- and I'd *still*
get the wrong coordinates! (because the user was fast enough to get the penUp
and a second penDown before Fitaly got the first penDown)
Either way, I've got the wrong coordinates.
In my humble (ok, less than humble... :) opinion, the penUp coordinates *should*
contain the accurate coordinates (after all, the penDown coordinates are right,
so at the very least the penUp could be the same coordinates, and they'd be
almost completely right; the only time they'd be wrong is if the user dragged
the pen and lifted before the pen-up position could be accurately determined.
In Fitaly's case that would mean a not-capitalized letter because the "slide"
wasn't recognized - still far better than a spurious capitalization because the
pen-up coordinate is *totally* wrong)
If the penUp coordinates were correct, Fitaly processing can lag behind and
still be correct.
The problem is that Fitaly needs to handle some of the events, while the
application handles most of them; Fitaly doesn't remain in control all the time
(the way the built-in keyboard does)
- Al -
--
-- Alan Weiner -- [EMAIL PROTECTED] -- http://www.ajw.com
