Clarifying form/gadget event handling vs other events

[bsilver]

Greetings. I know it's best to check for and handle events that affect graphical gadgets from a single "main" event loop, so procedures and other threads must pass updates back to that primary event loop procedure to have updates properly processed.

Does this only apply to graphical widget events, or should that event loop also handle things like network events...all events regardless of whether it influences graphical items or miscellaneous system events?

[jacdelad]

Hi,
since the Network library uses own events, not connected to the events given by WaitWindowEvent(), you can put the network-event-loop into thread or use a timer to process it within the "normal" event loop. Still, you absolutely should process it in one loop, just like the main loop.

[spikey]

It depends what your specific program is doing. There's no single right answer but there are a few wrong ones to avoid.

1) If you have two (or more) windows with their own separate event loops, opening window 2 will stop window 1 responding until window 2 closes (or vice versa). This is a scenario that you need to avoid if you want to have concurrent window activity.

2) Updating UI gadgets directly from threads other than the main one is not supported and will cause crashes sooner or later.

3) One thread can only service one loop at any one time and if there are a lot of UI events and a lot of other events this may cause a program to appear laggy or even faulty. For example, this design for handling network events won't work properly at all even though the code might look reasonable:

Code: Select all

Repeat
  Repeat
    UIEvent = WaitWindowEvent()
    ; ... UI event responses.
  Until UIEvent = 0

  Repeat
    NetEvent = NetworkServerEvent()
    ; ... Network event responses.
  Until NetEvent = 0
Until Quit

It will halt at WaitWindowEvent() if the UI is idle; network events will then stop being processed until something happens in the UI again. Bad news if the program is supposed to be a network service!

I can improve it by using WindowEvent() or WaitWindowEvent() with a non-zero timeout but there is still a balancing problem. If a lot of window events are being processed, network event responses will get delayed. If there are lots of network events, window event responses will be delayed.

I'm not sure how other operating systems handle checking for a crashed process but Microsoft Windows keeps a track of how many events are currently queued for a program. If the program stops removing event data from the queue, it is deemed to have stopped responding and the user will be advised as such. If the user then takes the opportunity to force quit the program, this could have undesirable side effects because files may not be tidied up or closed down properly.

As jacdelad said, I can get around this properly by using the main thread to handle UI events and a subordinate thread to handle the network events. But threaded programs are more complex to write and maintain and way more complex to debug than single threaded ones.

[Fred]

You can interleave this if you want to avoid too much delay in case of event flooding (one WindowEvent() the one NetworkEvent())