Multiple Message handlers in a QMH?

[Shiv0921]

My project is based on a QMH and currently runs ‘manually’- relying on interaction with the UI to do anything. I want it to also have an ‘auto’ mode where a command list is created from a tree and then read one by one, running through this list.

Can I get some advice on how to best send these commands through my program? I feel like I have two options.

1) Use the main message handler to read and execute the list, but commands like ‘wait 120s’ (common command) will effectively freeze the UI as it won’t receive even priority messages until after this.

2) Have a second message handler which only deals with the command list, mirroring the functionality of the first but receiving all of its messages from the list and not from the UI.

I feel like the second might be the way to go? But it feels a bit spaghetti codey adding 2 extra loops (tree->list & message handler) just to get this auto mode.

Thanks

Siobhan

code attached (if it helps?)

[Kevin_Price · Accepted solution]

Here's what I picture: the 2nd loop would be the auto command processor.   It just sends those commands sequentially over to the main QMH loop.  When there's a "wait", the 2nd loop does the waiting before sending the next command.

I assume you want manual mode and auto-mode to run the exact same code for each command, right?  I'm also supposing you want these modes to be exclusive so that only 1 command source can be active at a time.

I'd have the main loop be in charge of launching the 2nd loop into action when going into auto mode.  Then it can also do what it needs to prevent manual commands from interfering.  A simple thing might be to disable the GUI items associated with commands.  (A subtlety to watch out for is to make sure there isn't a backlog of manual commands in the loop's queue when the auto mode loop is launched.)

When the 2nd loop finishes auto-mode command processing, it sends some kind of "Done" message back to the main QMH and then terminates.

That's a rough overview of some initial thoughts.  But keep listening for other responses too, I make no claim these ideas are "best".

-Kevin P

[Shiv0921]

Riiighhhtt! Thank you! That's a much better approach than what I had initially envisaged. I'm still trying to get my head into labview thinking. Cheers!

[johntrich1971]

I would probably go with the first option. It just seems cleaner. To handle the Wait issue I would break it up into a series of smaller waits, likely queuing up at front an additional wait until the wait time has expired. This could be done, for example, via a user event. In the user event you can check that the next item in the queue is not a priority event. If not priority event then queue up an additional wait as a priority event.