(I also posted this reply over on pilot.programmer, but wanted to be sure
people saw it.)
"Greg Martin" <[EMAIL PROTECTED]> wrote in message
news:mI$[EMAIL PROTECTED]...
> Ben,
>
> Thank you for your answer, but there is something more going on. I did
state
> it badly by using the term "taking over" INetLibGetEvent(). Let me explain
a
> little further.
>
> In the debugger, I can watch my event loop process events. Normally, calls
> to INetLibGetEvent() return network events during wireless transactions
> (i.e. http requests) and everything works great. But, when you press and
> hold the stylus on a Palm control like a button or scroll bar it appears
> that INetLibGetEvent() doesn't return until the pen is lifted or moved.
> Fine, that's bad and it fits what you said about EvtGetPen(), but there's
> more.
>
> If hold down on the scroll bar and then begin moving it up and down (i.e.
a
> bored user "playing" with the scroll bar), calls to INetLibGetEvent()
return
> with sclRepeatEvent. That, of course, is to be expected. What was
unexpected
> is that while INetLibGetEvent() is returning loads of sclRepeatEvents, no
> network events get returned while the user is "playing" with the scroll
bar.
> It is as if the normal processing of INetLibGetEvent() is "taken over"
> internally by code that bypasses any processing of networking code.
Network
> events are again returned from INetLibGetEvent() immediately after the
user
> lifts the stylus. If the user plays with the scroll bar at the wrong time
> for too long, you get a timeout error as soon as stylus is lifted -- I
would
> describe it as the network code starving to death waiting for
> INetLibGetEvent()'s normal network processing to resume.
Hmm, interesting problem.
sclRepeatEvents are produced by SclHandleEvent, and they are enqueued using
a standard EvtAddEventToQueue() call. The scroll bar handling code works
like the normal control code, grabbing pen movement. The difference is that
hey have a timeout which will send the repeat event after a specified number
of ticks. They start this tracking loop on either a sclEnterEvent or a
sclRepeatEvent, which is why you must not return true for a sclRepeatEvent,
because that prevents it getting routed back to here.
So, while the user is moving the scroller, the system will always be tied up
in pen tracking (in SclHandleEvent) or be processing a sclRepeatEvent in
your loop.
The 3.5 sources don't include the INetLib code, so this part is only
speculation, but I would guess that they would always defer to events in the
event queue, passing those along before providing any INetLib specific
events.
So... one way to get around this would be to modify your event fetching to:
1) Check EvtEventAvailable() -- if there are events posted, do your own
manual INetLib checking using calls to INetLibSockStatus, and pass on your
own "made up" events if the status indicates that there is data ready.
2) Otherwise, call INetLibGetEvent(), so you'll get normal UI events, and
not have to poll for future status changes.
Thanks for making me look into this -- I'll need to deal with this too in my
code.
Good luck!
--
Ben Combee
Veriprise Wireless <http://www.veriprise.com>
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/tech/support/forums/
