Let me politely suggest that you *might* be doing some premature optimization that may not be necessary.
When you expressed your concerns about extracting a full array of queue elements using the preview function, I figured maybe your queue elements were large and memory-heavy - like kB per queue element or something like that. It now sounds like they're either scalar elements or perhaps a pretty limited size array or cluster of scalars.
I respect how it bothers your sense of efficiency to pull the whole array just to retrieve the latest element, but that inefficiency may very well may not be discernible at all in a practical sense. If you're just doing it a few times a second to update a few screen indicators, you're not going to run into problems.
I'd tend to recommend the "inefficient" approach over either of the following 2 approaches:
1. Maintaining a "most recent value" variable.
2. Redundant updates to both a queue and a notifier.
While either approach is probably a little more "efficient", the problem I'd have with them is that they require the "producer" part of your code to have detailed awareness of the "display" part of your code. Your decision about which parameters need to be written to a "most recent value" variable or to a notifier would be embedded in the code for your producer.
It's generally more modular and extensible if the "special logic" is contained withing the module that needs it. Here, that means that you let the producer simply enqueue without regard for the display's special needs, and then confine the special data handling to reside in the display-related code.
Again, general rule of thumb. There can be good reasons to build in tighter coupling when needed, but it's *typically* better to aim for loose coupling.
-Kevin P
ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
