I wanted to ask for some advice.
Usually when I implement a producer consumer I use the producer to create queue elements with an enum state and pack all the data necessary to process the event in a variant.
Then the consumer does all the work.
There are two areas where I feel like I might not be using the best approaches..
1) When I have to update a front panel control I pack a reference to that front panel control into the variant so I can access the property nodes in the consumer and update it.
I attached pictures with an example. It is simplified code where the user has to run some DAQ task while scanning some parameter. The code increases the parameter by a set amount with every run to aid the user in his scan.
Is there any better way of doing this?
2) When events require the same control to be wired into the variant for handling by the consumer loop I create local variables or references to that control in other events. Would it be better to have a shift register running through the producer loop that gets updated front panel values at every while loop iteration?
Solved! Go to Solution.
Avoid use the "Value Property" for feed data to UI ( if it was a control, use local variables instead, but if u are creating too much, something is wrong with your approach ). If u need use the reference to manipulate one property, so handle it directly on event structure, but if u need to "switch control state" based on another loop, then it's more appropriate to handle this using another way (perhaps, create another loop and send the message ). IMO, there's no need to pack the reference to manipulate some UI element. You should handle this with single VI using the "Controls" property node and iterate over using one search word (Label?). Here's one example (it's not snippet) to catch one reference of a control in one tab control (The another VI check the equality). Ignore the numbers...
Another approach to this (IMO, more simple) is create one Event Structure with a single custom event using the Enum/Variant approach to feed the value (Controls = Locals). Personally, i like this approach cause is one queue less to mantain xD
Let me know if i made it clear (or not....).
Anyway, sorry for my bad english 😛
Since you are using an event loop as the producer, I would use User Events to update your controls. This way you aren't passing around references just to set/update a control. Instead, you make a user event and handle that event with your event structure. Your consumer just sends the event with any data that is needed. I found this setup really useful since it keeps all of the GUI code centralized in a single loop.
Thanks for your suggestion. In your picture, what is the VI with "UI" and the magnifying glass called?
Thank you I really like your suggestion of using user events to manipulate front panel controls.
Do you have a suggestion for my second question? When events require the same control to be wired into the variant for handling by the consumer loop I create local variables or references to that control in other events. Is that a good approach?
Here it is:
The VI receives a Label (UI element that i want to find) and the array of controls (In my case, the controls in one tab control page). If found, the loop finish. Of course, my approach was designed to deal with "dozens of controls". If it isn't your reality, so you can "register" the few UI elements in one shift register and operate using one separate loop (UI Loop) or handle it directly on Event Structure (the both sounds reasonable to me).
@pulsed_power wrote:When events require the same control to be wired into the variant for handling by the consumer loop I create local variables or references to that control in other events. Is that a good approach?
This is one of those perfectly acceptable places for a local variable, but only within the event structure. Just be careful if you are reading and writing with locals. That could get into a weird race condition based on when certain events are fired. I discourage the use of references unless you are setting more than just the value. They do cause thread swaps and slow down your program.