Updating runtime shortcut menu in an producer/consumer structure

[seb_bd]

Hello Community!

I am developing an application using an event-driven queued state machine. 

I would like to edit the runtime shorcut menu of a Tree indicator according to which item is clicked. To do this, the event loop listens to the event "Shortcut Menu Activation?", retrieves the right-click coordinates and passes it to the "Point to Row Column" Tree Invoke Node, which in turns outputs the Tree tag that was clicked. I pass this info and the MenuRef to the action loop by a queue.

I expect the action loop to look into my tree items, determine which "type" of item it is, and update the shortcut menu accordingly.

Unfortunately, as the event loop has already finished its job, the event is registered by LabVIEW, the menu opens and the reference "dies", so I cannot edit the menu through the action loop.

I could set the Discard boolean to TRUE, but then I cannot force the shortcut menu to open.

Also, I would like to avoid putting the runtime menu edit in the event loop, because this will probably slow down the execution, and I would like to keep all the tree data in the action loop only.

What is the best way to do that? Thanks for your help! 

[drjdpowell]

This is one of my biggest dislikes about the typical "Producer Consumer" design.  One takes a highly-capable Event Structure and throws away it's advantages by queueing to a more limited second loop.  Seems at best pointless.

[seb_bd]

@drjdpowell  what do you suggest then? Your comment only criticizes what I am doing with no solution. I am eager to learn how you would do it.

[drjdpowell]

I would combine the two loops into one.  The JKI Statemachine is a common one-loop design you could look at.

[seb_bd]

What if the action/consumer loop is slower than the event/producer loop? Say, the action loop makes an API call that takes a few seconds, but I still want the user events to be registered?

How can this be done with a single loop?

[Ben]

There is no law against having more than one Event Structure so consider adding an event structure loop to handle only the menu functions.

Ben

[drjdpowell · Accepted solution]

That might be a reason for a second loop, but not in the way of the standard "Producer Consumer", which just throws all User interactions onto the Queue.  Look at your posted PNG: if your "action loop" is busy for a couple of seconds, then any action you send to it will be delayed.  The solution is to make the event-structure loop the primary one, which handles most events directly, and (maybe) have a specialized loop for only the long-running action.

[seb_bd]

Thanks for your suggestions.

@Ben, I don't see how a second event loop (specific for the menu events) can help in my case. I have no trouble registering the shortcut menu activation menu, but I don;t have access to the data needed to edit the shortcut menu in the event loop. Adding an extra event loop doesn't solve the issue.

Latest suggestion of @drjdpowell is interesting though. I can have a specific process (loop) just for the API calls (that are the longest actions of my application anyway) and do the event+interface+other short data actions in the main loop, which in this case will hold all my relevant data. I think that should do it, thanks!

[drjdpowell]

 BTW, a "specific process loop" that just does one task for a primary loop is often called a "helper loop".