GUI event handling architecture

[hellopic]

I am trying to change the structure of the code that someone else has written. It is basically a home automation system with a monochrome graphical GUI. There are over 50+ different screens that the user can cycle through to set and monitor various things. There is also the application logic that does all the behind the scene stuff.

The current architecture is that each gui screen is a case-statement of large switch-block. Within each screen, there is some code that just displays stuff on the LCD and event handling (button presses, request from application logic to change screen etc). The event handling is implemented as a if-statement for each event.

Now, the problem is that some of these events trigger actions that need time to complete and the screen should not be exited before that, which would could leave the system in an indeterminate state. There are a whole bunch of flag-bits that are set and checked in the even handling code and sometimes it does lock-up (race conditions or something like that).

I am thinking, a better way to do it would be a state-machine (switch-block) for handling events in each screen. So case 0 would be the event handler dispatcher(so to speak) and depending on the event, it moves to another state where the event is handled to completion and goes back to handle more events.

The up-side is clean code, correct implementation. The down-side would be that no concurrent handling of slow and fast events. For example, an event may be to just turn on the LED, while the another event may be to analyze log data or something - then the LED event would have to wait which may be perceived as a sluggish gui response.

How are such architectures usually implemented?

Sorry for the long post but thought it could be useful to others as well.