I wanted to add the following information to explain better by what I meant
when I said that something "takes over" INetLibGetEvent().
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, but there's more.
If you 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.
If I had access to the Palm source code, I'm sure it wouldn't be hard to
find out why this is happening. I was hoping against hope that there might
be a way to change the behavior so that calls to INetLibGetEvent() would
return network events while the user is "playing" with the scroll bar or
other Palm UI controls.
Greg
"Greg Martin" <[EMAIL PROTECTED]> wrote in message
news:34469@palm-dev-forum...
>
> I'm sure there is no workaround for this Palm OS network event bug, but I
> figured there is no harm in asking.
>
> If you go into any PQA app and hold the stylus down on a button or scroll
> bar while you're wirelessly retrieving data (i.e. tap a hyperlink in a PQA
> app and then tap and hold down a button or scroll bar), you'll notice that
> the network indicator stops functioning. I don't yet have access to the
> Palm OS source, but obviously that because the Palm OS library's event
> handling code for controls must be "taking over" INetLibGetEvent() and
> skipping calls to the inet/net library. In essence, while holding the
> stylus down on most Palm OS controls INetLibGetEvent() becomes, in
essence,
> simply a call to EvtGetEvent().
>
> What this means for any networking application is that it gets starved of
> networking events as long as the user holds down the stylus on a Palm
> control, i.e. a bored user waiting for a reply may "play" with the scroll
> bar and essentially halt networking events. If you hold down the stylus
> long enough at the right time, you get a network timeout error as soon as
> the stylus is lifted. I think most PQA apps handle this by basically
> displaying no content.
>
> I came across this problem in our Palm C application and there doesn't
> appear to be a workaround especially since it is so easily reproducible in
> PQA apps. I was able to verify in our Palm C app that when the stylus is
> held down on a Palm control, no network events are returned from
> INetLibGetEvent() and it basically behaves just like EvtGetEvent().
>
> I was just wondering if anyone, by some miracle, had a workaround.
>
> Greg
>
>
>
>
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/tech/support/forums/
