@Ben wrote:
Aside from the easy overview of what is handled in this mode I also free myself from issue with users punching buttons for the other mode (no need to track mode internally to dicide if i should act or not).
more often that not these days, the larger apps don't get an event structure and they act as a container for the FP object and mode control code.
Prior to Dynamic event registration my top level GUI could have dozens of events to handle all of the modes.
I didn't address these comments directly so I thought I'd take a minute to explain how I would refactor Ben's code to remove the functional code's dependency on the UI using a messaging-based system. Looking over it a bit more I don't think it would be that difficult to do, though it does depend on details that aren't shown.
The state machine shown in the sequence structure is good. I'd start by defining a set of input messages the state machine as a whole can respond to. You can think of these messages as requests, not commands. We're asking the sm to do something. Each state responds to the subset of messages that are appropriate for that state. Any request can be sent at any time, but the sm only reacts to messages that its current state supports. The sm controls its own behavior rather than having its behavior controlled by an external entity.
The UI bd contains an event structure for the fp control events. Each event case simply sends a message to the functional code requesting some action be done. The sm will act, or it will not, depending on if the current state supports the message sent. Users can punch all the buttons they want for the other mode. The sm simply ignores them as irrelevant.
To enable UI features such as disabling controls, I also define sm output messages. "StateChanged" output messages containng the new state are fairly common. The UI code registers* for this message. When the UI receives a StateChanged message it enables/disables fp controls based on the new state. The UI has changed to give the user feedback on what is allowed and what is not, and you can easily implement more stringent restrictions than what the sm allows, but there's no way to make the sm do something it does not explicitly allow.
(*By "registering" for a message I simply mean implementing code that reacts to the message. The mechanics of registering depends on how the sm output messages are sent to the UI. If using a queue, simply add a case for that particular message. If using user events, add an event case for that user event. Note that the UI doesn't have to react to all messages sent by the sm. When implementing the sm I'll create output messages for things I think I will need later. Sometimes I end up not needing them, so while the sm still sends them the UI just ignores them.)
The execution sequence would go like this:
User clicks button to enter collect mode, UI event fires
UI bd posts "EnterCollectMode" message to the sm's input queue.
SM dequeues message, confirms it can transition to the Collect state, and initiates the transition.
SM arrives in the Collect state and posts a "StateChanged" message to its output queue.
UI bd dequeues the StateChanged message, reads the new state, and updates UI fp accordingly.
User notes Analysis buttons are now disabled.
