How to handle a controls menu activation in a producer-consumer application?

[Basjong53]

I have a control with a custom run time menu. My application has a producer-consumer architecture. So the user events are handled in one loop, and all data management in another loop. When I activate the menu of the control, I want to modify it based on the data in the data management loop. For example, if a measurement is ongoing, the menu should have a stop option. Or when the measurement is complete, it should have an "open measurement file" option. But when I send the menu reference from the user event loop to the data management loop to act on it, I get error 1160: illegal menu.

I understand this is by design, so I should handle the modification in the event structure. I was taught to avoid having any functional code inside event structures. It also goes against the design of the producer-consumer architecture. I seems strange to have to send data back from the consumer (data management loop) to the producer (user event loop) in order to modify the menu properly.

What would be the best practice in this case?

[GerdW]

Hi Basjong,

---

@Basjong53 wrote:

I was taught to avoid having any functional code inside event structures. It also goes against the design of the producer-consumer architecture. I seems strange to have to send data back from the consumer (data management loop) to the producer (user event loop) in order to modify the menu properly.

---

No need to enlarge the font size so much…

• Who taught you to avoid "functional code"? Code should always be functional…
  (Typically you should avoid code needing long time to execute inside event cases.)
• Which "data" do you need to send from consumer back to producer?
  As long as it is only the current state of the consumer I see no reason to avoid an user-defined event to send data to the producer…

[Basjong53]

No idea why the font is so big...

Basically, I use the event structure only to queue the next state in a state machine or a send a message to a consumer. The actual "work" let's say, is then done in the appropriate state/case.

The actual use case I want it to update the menu of a tree control. The application performs several measurements in sequence, updating the tree control after each measurement. When the user right-clicks an item in the tree control, there should be the options to open the file, copy the data, etc. But these options should only be allowed if the measurement was successful. 

So you are suggesting to create a user event to send the measurement state from the data loop to the user event loop and keep it there in a shift register? Or maybe keep a global variable/FGV with the states?

Sorry if this a trivial question, it's just a situation I haven't encountered before.

[FireFist-Redhawk]

If you have a column that displays current state of each measurement, not started, in progress, passed, failed, aborted, etc, you could determine which menu items you need within the producer loop, just from the tree reference. If you don't have something like that, then you could potentially add it, shown to the user or hidden, or use a user event or global. I would personally be hesitant to use context-sensitive right-click menus though. They can't change context once they've been activated. For example, what happens if the user right clicks in the middle of a measurement to stop it, and it finishes before they click the option? Also, RCMs have less discoverability. The user only knows about them if they've been told somehow, or they randomly right click and see them.

[Basjong53]

---

@FireFist-Redhawk wrote:

If you have a column that displays current state of each measurement, not started, in progress, passed, failed, aborted, etc, you could determine which menu items you need within the producer loop, just from the tree reference. If you don't have something like that, then you could potentially add it, shown to the user or hidden, or use a user event or global. I would personally be hesitant to use context-sensitive right-click menus though. They can't change context once they've been activated. For example, what happens if the user right clicks in the middle of a measurement to stop it, and it finishes before they click the option? Also, RCMs have less discoverability. The user only knows about them if they've been told somehow, or they randomly right click and see them.

---

I like the idea of having the information in the tree control itself. I'll see what I can do with it, thank you.

I agree that right-click menu's should be used sparsely, but right-clicking a tree with a list of file/folders is very similar to Windows Explorer, so users should already be somewhat familiar with it and expect to have some form of menu in it.

[altenbach]

---

@Basjong53 wrote:

I seems strange to have to send data back from the consumer (data management loop) to the producer (user event loop) in order to modify the menu properly.

What would be the best practice in this case?

---

The UI loop should do just that: control the other loop. I would keep all state information in an action engine that gets updated and read in both loops. You can use the timeout event to check it at regular intervals.

[BertMcMahan]

I think I would word it as "The UI loop should control the UI". When you frame it that way, updating what the menu options are is well within the "responsibility" of the UI loop.

And to the OP, sending info back from the consumer loop is fine. I'd suggest conceptualizing it as "I have sent a status update to the UI loop". Don't try to update the menu within the consumer loop, as that's what the UI loop is for. In that paradigm, the consumer loop is notifying the UI loop that there is a change. The UI loop can then decide what, if anything, to do with that message.

As stated, an action engine/timeout is a perfectly fine way to do this. As are the other suggestions for a FP control or user event (my preference, if you already have an event structure).

Basically... the idea isn't so much that you're "not doing work" in the UI loop, it's that each loop is doing its own thing semi-independently. So the consumer loop consumes data and the UI loop handles the UI.

[RTSLVU]

---

@Basjong53 wrote:

No idea why the font is so big...

When the user right-clicks an item in the tree control, there should be the options to open the file, copy the data, etc. But these options should only be allowed if the measurement was successful. 

---

User Event (click on the menu)

Check to determine if the measurement was successful. The simplest way would be a (gasp) Local Variable in your measurement loop.

Then display the appropriate menu items based on the status of the measurement success Local