I've got to agree with John on this!
- On the pdQ, the phone display which includes the data call timer and RF
signal strength all require the current app going though the main event
loop occasionally. They won't update otherwise.
- I think of select as an optimization that hints when it's a good time to
call your I/O functions and check for events. There's a couple of cases
where it doesn't pop when it should (I believe the other is when a close
finishes). That of course means your I/O has to be prepared for the case
when nothing can be read or written.
LL
At 10:11 AM 1/7/00 -0800, Schettino, John wrote:
>I'll take a crack at this one ;)
>
>I'll come right out and say I don't agree with your design. When you're
>doing network I/O, it's better to put the select in your main event loop,
>and then deal with reads in the form event handler. Essentially, you get a
>NIL event from the event loop, and in the form handler for the NIL event you
>do one read on the socket with a very short timeout. Once you read EOF
>you're done. Assuming the user does something else (like tap a cancel
>button, or exit the form, or the app) you close the network connection &
>otherwise clean up. That way, all the other interface elements remain active
>and the user stays in control.
>
