Ther are 10 pages of suggestions coming up when typing "probe location on wire".
AFAIK, none of them addresses this irritating behavior of probes:
The probe icon will snap to some algorithmically determined location which might result in illegible data flow during debugging, or might end up in a region of the diagram far from where the critical action takes place.
I know that what matters should be the VALUE of the probe, but WHEN to check the probe value is also critical, and in a visual development environment, this time is determined by monitoring the data flow (among other methods). This is where this uncontrollable probe location can be annoying at times.
My suggestion: just as for labels, let the user choose the location of a probe anchor point on a wire (especially when it branches off).
When reviewing old projects or VIs, the "VI changed" title bar star is always only a few mouse clicks away. And beware of accidentally opening an old project with a newer LabVIEW version!
You all know the "vi has unsaved changes" dialogs that follow when just wanting to close the windows, and who has not at least a dozen times saved an old VI in one of these situations just out of a misplaced click or the habit to save your code whenever you you are prompted to...
This is why I propose a new file menu entry: open (locked)... or open (read-only)... or an "open options" control in the file dialog.
Its functionality would be to open the selected file or project in a similar way like the locked VIs: you can look at them, browse through case or event structures, but cannot change a thing...
Even better would be the option to allow changes (e. g. move/delete some portions before selecting the rest for copy&paste), but to prevent re-saving the file under the same name. For this case, trying <CTRL-S> or closing the file would open a dialog stating that the VI was opened as "read-only" and that you may either discard the changes or save the file under a new name.
Of course, this "read-only" flag would be inherited to all subVIs, typedefs etcetera that would be opened from the original project or VI.
And to make my whishlist complete, a color coding of the VI window / project frames would signalize the read-only state of the code:
By the way: Wouldn't it be nice if VIs in vi.lib featured this opening mode by default?
When wiring a VI, a cardinal sin is to put nontrivial wiring behind the VI icon. I see no use cases for this invisible wiring, and it directly causes many errors. In particular, accidentally wiring up the output of a bundle operation to the 'cluster in' box, so the bundle operation is completely ignored, yet the code looks perfectly OK.
This would be very easy to prevent. Help us not do things like that by letting us enforce the constraint:
When wiring or moving VIs or other structures, enforce the constraint: wires cannot cross the line separating two terminals.
By 'lines separating two terminals' I mean any of the interior lines on the wiring diagram that have at least one side being a valid terminal. For instance, I've marked in red the places wires should not go (using the terminal diagram, even though you never see the terminal diagram on VIs on the block diagram)
If you do something that would cause such a wiring abomination:
Check to see if the wire simply crosses the border and then crosses back (a common case). If so, cut off the part that transgressed and connect the two severed ends inside the terminal.
Otherwise, push the offending wire out the side of the VI. If this movement causes it to cross a boundary in some other VI, introduce a wire bend halfway between and solve the halves independently. If no solution can be found - VI's are on top of each other, say, complain bitterly (red X on wire).
Only enforce this constraint when editing (such that you're creating the problem), not when reading the code. That way, noncompliant code is not broken.
Getting a value change event on a shared variables seems to me like something that ought to be expected "out of the box" in LabVIEW. Polling shared variables for changes is taxing on resources, and such an architecture is generally frowned upon by NI and the LabVIEW community for things like front panel interactions and the like. Why, then, should we expect to pay extra to deploy applications which such an architecture for interacting with shared variables?
I completely understand the extra license for the DSC run-time, as there are numerous other terrific tools included. It just seems to me that the SV value change events are one thing that should be freely available for deployment to everyone already paying for the application builder.
There are two undocumented events for arrays:
which are unfortunately lost when you replace the array contextual menu by your own.
They could in principle allow finding which element a user has deleted or inserted. Indeed, sometimes "OldValue" and "NewValue" are not enough to infer this information (think about identical values in an array).
The only additional information currently provided is "Coords", which tells where on the FP the user event was generated.
In principle, it should be feasible to get back to the location of the element involved and from there find out the element's index, but add scrollbars, panels etc, and that rapidly becomes a project by itself. Moreover, you can "insert" a value to the end of an empty array control and the inserted element will anyway be "inserted" as the last element (which also be the first and only element).
In other words, after having carefully computed where the click took place, you will still have to figure more about the control itself to make sure all the corner cases are covered. Big PITA.
Instead, I'd suggest to have both events also output the array index (or colum/row, in the case of a 2D array (*)) where the event occured. This is a known information to LabVIEW, since the control is updated just fine.
Now there is still the issue that the insert and delete element events are accompanied by a synchronous "Value Change" event, but that can be dealt with in a rather simple way (as long as you are aware of it).
So in summary, my suggestion is, as the title indicates, to provide an "Array Index" output for the "insert..." and "delete element from array" events
(*) Notice that there is no such shortcut event for array with higher dimensions...
Right now - Requried Terminal is identified by either 1. Bold text in Help window 2.Broken arrow.
Will it be posible to highlight / mark the required terminal, so to identify at first look ? Something like mentioned below.
Sorry i couldnt draw properly. but some thing like this to highlight both in FP and BD.
Wire : Right Click --> Visbile --> Label (Its void Now )
Solution : It can take the control Name as default label of the wire, instead of being Void
Not sure if this idea is already proposed.
(Inspired by this discussion)
The Index & Bundle Cluster Array function currently discards any labels of the input data. I think it would be more useful if it would try to retain the names (i.e. copy the original array labels (if available) to the element labels of the output).
The picture illustrates the idea. On the left we see the current behavior and on the right what we would get after this idea is implemented.
NI updater kindly informed me that LabVIEW 2014 SP1 was released (even though I uninstalled it shortly after I tried it last year) and out of curiosity, I took a look at the known issues list.
I learned a few interesting things I did not know about, and also that some problems had been reported as long ago as version 7.1.1. This type of stuff looks like bugs that won't be fixed, ever.
For instance, CAR #48016 states that there is a type casting bug in the Formula Node. It was reported in version 8 and the suggested workaround it to use a MathScript Node instead of a Formula Node (where is the "Replace Formula Node by a MathScript Node" contextual menu item?).
Problem: the MathScript RT Module is required. Even in my Professional Development System, this is not included by default. Does this really count as a workaround?
I read: we don't have the resources to fix that bug, or we don't want to break code that expected that bug.
In any case, this bug with most likely never be fixed.
The bottom line is, we can waste a lot of time as users, rediscovering bugs that have been known for a while and will probably never be fixed. As a user, I would really appreciate a courteous warning from NI that there are known traps and have a complete description handily available with the help file related to the affected function.
My suggestion: add a list of known issues (with link to their description) for all objects, properties, functions. VIs, etc, in the corresponding entry in the Help File.
.net and many other languages have an intuitive and simple way to allow you to define how a window behaves when you resize it: anchors. Anchors allow you to define the distance between an edge of a child control and the edge of a parent control regardless of the size of the window. The size of the control itself stays constent unless it violates the rules of the defined anchors in which case it changes sizes to meet those rules. For example a front panel with the following anchors:
Would be resized into:
After deleting items I don't want in the project, or loading plugins in a plugin architecture, I want to remove them from the LabVIEW memory. This is not possible now, as they go into Dependencies->Items in Memory.
The only way to do this now is to close and open the project, which over a large Plug-in architecture project is a real pain.
Ideally, I would like to right click the folder and choose "remove from memory". However, any option that allows this would be good.
Aesthetic issue: thick wires connected to Select inputs show as ugly corners behind the triangle icon, probably a result of the underlying connector pattern.This does not happen for other triangular blocks, at least not up to a reasonable wire thickness (to make a wire thicker, just make a N-dim array of something).
Problem: my code accesses many different properties of many different controls. I need to locate where a specific property of a particular control is read/changed.
I know that the Find panel offersi me the option of searching by text, like
but that is not the solution, because I need to type thename of the property, and because I may match many other objects with the same string (comments, other controls with the same property, etc.)
I'd like a faster way to get to where I need. For instance the contetual menu could offer Find/specific property according to where the right-click was.
Very simple idea that can make locating the basic comparison functions more efficient (first two lines). Changing the order putting each comparison function and his counterpart below him would make easier to find the desired one.