So when it comes to using a queue, there is a somewhat common design pattern used by NI examples, which makes a producer consumer loop, where the consumer uses a dequeue function with a timeout of -1. This means the function will wait forever until an event comes in. But a neat feature of this function is it also returns when the queue reference becomes invalid, which can happen if the queue reference is closed, or if the VI that created that reference stops running.
This idea is to have similar functionality when it comes to user events. I have a common design pattern with a publisher subscriber design where a user event is created and multiple loops register for it. If for some reason the main VI stops, that reference becomes invalid but my other asynchronous loops will continue running. In the past I've added a timeout case, where I check to see if the user event is still valid once every 5 seconds or so, and if it isn't then I go through my shutdown process.
What I am thinking is that there could be another event to register for, which gets generated when that user event which is registered for, becomes invalid so that polling for the validity of the user event isn't necessary.
When autoindexing on a WHILE loop input tunnel, we get the default value for the datatype after we run out of elements on the autoindexing array. I can think of several scenarios where it would be useful to simply start over with the input array.
I propose a new input tunnel type (looping) which would do exactly that: index the elements to the end of the array, then start over from the beginning, ad infinitum (or until the loop stops).
(The same would of course also be useful for FOR loops. Here it would not be used to determine the loop count, because it never runs out of elements.)
Here's how it could look like in the code. (On the right, I show explicit functional equivalents).
When I Control+Right click and drag to expand a block diagram. The expansion should NOT effect all of the unseen case frames
I am really tired of stuff like this happening when I expand the diagram of another frame of the same case horizontally and vertically.
This "Short cut" actually creates a lot more work for me as now I have to go back and clean up all the other states in my state machine that are messy now.
When dragging a control / indicator label or caption, if you move within a certain distance from the owning terminal the label will snap to one of a set of given positions (top-left, top-middle etc). Outside this distance (or if the user presses the spacebar to toggle this behaviour), the label can be freely positioned.
The selector terminal for a polymorphic VI should display the same behaviour with regard to the owning VI icon. A polymorphic selector is currently always free-floating.
PS : Many thanks to Intaris and TiTou for their help to formulate this idea.
Expanding a little on the idea I hinted at in this recent thread, here is something that strikes me as a missing feature in LabVIEW.
I'll start with some illustrations.
Starting situation: let's say I have a main VI and I create a new case in a case structure, because I need to perform some data processing. I drop a few property nodes, references, have data flowing from shift registers left to right , and I pull a Data Value Reference wire from a big data structure:
New feature 1: I drop a BLANK VI on the block diagram (which I choose with the appropriate number of connectors):
New feature 2: I now CONNECT my inputs and outputs to this blank VI:
ending up with this:
New feature 3: Now, I can double-click the blank VI to open its panel, which reveals a neat FP and a BD with the Controls and Indicators I need (not shown). I now can start wiring the functions I need to implement.
But for faster readers, several bugs hinder the universal use of units in LabVIEW.
It is a wonderful system but should be completed in a way (at least the square function should be using it) but all the other remarks found in that thread like the identical look of the expression node and the unit, not working formula nodes etc. should at least be taken seriously.
I lik the system but for now it is hindered by too many bugs.
When a complex application uses deeply nested clusters to organize their application data, it can be difficult for others trying to extend/maintain that code if they are not intimitely familiar with the names and the datatypes of the elements within the data structure. Is that element a integer, enum, string, path, array, cluster, object?
The context help provided when hovering over wires and the color and texture of the wire on the diagram is very useful, but neither of these are available when you are attempting to select the correct element from the bundle/unbundle nodes.
I propose that the same datatype glyphs shown in the context help when hovering over wires should also be visible when attempting to select the correct element in the bundle/unbundle nodes.
At the moment, if I want to review my search results, I'm required to double click each item. This opens the diagram (usually) and the front panel. I then have to close them, or I might end up with dozens of open windows.
Of course I could use CTRL+G, but I'd still need to clean up the opened windows.
Another slowdown is that the highlighted item can popup anywhere on my screen(s). This "gaze time" adds up if you need to browse through dozens of results.
It would save me tons of time if the search results window had a preview of the result:
The found item should be in the center, preferably highlighted in some way.
It would allow me to give the listbox key focus, and use up\down to browse through all items very quickly, without any need to clean up!
Please let me opt out from this new feature, introduced in LabVIEW 2017, permanently in the setup dialog.
Using LabVIEW for a very long time (since LabVIEW 2.0), I never wished such a feature (it got only 27 Kudoes) - and - I am even using it's "anti feature", implemented up to now, constructively to detach objects (Pull control into a structure, connect it to the new target - and "Ctrl B").
This new feature, forced onto everybody, would be less annoying, if pressing "W" would reliably disable the feature. However, at least in vritual windows machines (Parallels) on a Mac, it does not work 50% of the time.
Did you know you can make property nodes and invoke nodes smaller by not showing the names?
Well, forget you know, it's a terrible idea to hide that information! You lose the self-documentating nature of LabVIEW. I use this as a comparison for Call Library Function Nodes (CLFN) - by default, these are dropped on the block diagram without showing names. I propose that the default is to show names for CLFNs for the sake of documentation, and so you don't have to hover over each terminal to find the one you're looking for. The biggest perk is simply the name of the function on the banner of the node. YES, there is a tradeoff between BD real estate and documentation, but I think "Names" trumps space virtually all the time.
It would be really cool to have a custom probe that could be placed on any cluster/class wire to view the data in the cluster, but instead of being displayed as a standard view of the cluster, the labels of the items would be listed along with the data type and the current value (works for scalar or small arrays, not so well for large arrays/waveforms). The standard view of a cluster probe is shown below.
I built a custom probe to do this but found that the data type of custom probes is strictly typed and therefore I have to convert my data to variant on the vi block diagram before adding the probe, which isn't great. I've attached the code for my custom probe, and a screenshot of it below.
If variant custom probes could be used on any data type, this would work.
If several cluster elements are hidden and we want to unhide them all, it gets tedious. For each elements, we need to:
Right-click the cluster...
advanced...
show hidden element...
select desired element... (At this time we have moved the mouse about 500 pixels to the right in steps 2-4!)
click outside the cluster to deselect everything (because now the cluster AND the element are selected and we cannot immediately start again with step #1).
start with step #1 for the next hidden element. Tedious!
I suggest that there should be a top entry <All Elements> (or more correctly <All Hidden Elements>, but that seems unnecessarily bulky and does not really add more clarity), to unhide all hidden elements at once.
Here is how it could look like:
Idea summary: There should be a menu item to show all hidden cluster elements with one simple step (see picture).
Sometimes it is interesting to programmatically operate front panel ctrols/indicators using not only references, but arrays of references to existing panel items.
Suprisingly, statically linked control references can be droped on the diagram and then programmatically combined into an array, BUT such an array can not be manually assembled at coding time.
It should be possible to do it (just like usual constant arrays can be made). It would be easier to code, and take much less room on the diagram.
Also, to make such a constant array easier to read (and gain diagram surface anywhere statically linked control references are used), why not replacing the type indication of the constant with the name ? Type can be checked by pointing at the output wire anyway...
Currently you can only set symbols of a Multicolumn listbox on the first column. I think it would be pretty handy to put symbols in any cell on the MCLB.
