Some times it is not easy to find the actual edited vi in the project window.
I would recommend to add an additional entry in the icon pop up window (front panel and block diagram window) that finds the actual vi in the project window.
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.
Project Properties / Conditional Disable Symbols / Description & Tips
There is currently no way to add a descriptive text in this window
(in the project properties dialog > Conditional Disable Symbols category, then right-click the table: Description & Tips).
How convenient it would be to be able to open a new "Description" prompt so as to describe each symbol you may want to add for a given project or target,
and especially the possible values that could be paired with the symbol keys. Upon editing a symbol, this description would help users and possibly prevent
them from checking out every single instance of the CD Structure to make sure the new symbol is the right one (espcially as there is no feature to locate the CD structures).
Add an editable Description dialog in the Shortcut Menu of the Conditional Disable Symbols table
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.
There are times when I don't really like the way feedback nodes make my diagrams appear:
I don't like the wires going back and overlapping things. This usually happens when there are a number of FNs in a single piece of code.
One way to work around this issue is to do something like this:
This splits the wire into two nodes and is essentially the "text based" approach - create a named variable and use it as a buffer. The fact that it's a local doesn't really bother me that much, even though that might raise the local police on me, but it does have some actual disadvantages - memory allocation (not usually a real consideration, but still), difficulty in setting an initial value, a technical possibility of creating race conditions if the user doesn't know what they're doing, it's harder to see that the two nodes are connected, etc.
So what I want is something which would combine the two - allow us to right click a feedback node and select Split, which would split it into two:
which results in this:
This is essentially like having a shift register without the loop. It ties the two parts of the node together and it should allow having an init terminal on the read node. In theory, it could also have a label. Also, note that in this case I didn't limit the vertical positioning of the nodes. This should be useful in cases where nodes are connected through elements which change the height of the wire, like Build Array or Select.
If you want to see some more opinions on this, we discussed it here a few years ago - http://labviewartisan.blogspot.com/2009/03/why-are
Also, here are a couple of alternate visuals, just for completeness, although I don't really like them:
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.
When you use TabControls in sizeable front panels,
you can only "Fit to pane" or "Scale object with pane"
to the tabcontrol itself !!!
But not for Its content !
Please handle the Tabpages as pane in order to be able to create userfriendly operator interfaces !
(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.
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).
We have developed an external DLL that is called from LabVIEW using CLFN. I have noticed a weird behavior regarding DLL detaching (unloading).
I have 2 VIs calling the DLL. I run them and then close all of them. In this case, the DLL is detached when the last VI is closed.
However, if I create project containing the same VIs as in scenario 1, when I close all the VIs after running them, the DLL stays loaded until I close the project.
This behaviour does not seem correct. I think LabVIEW should behave the same in both cases.
What do you think?
[admin edit: I changed the idea title per user request. The original title was "DLL shouldn't stay loaded when all the VIs calling it are closed".
.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:
This should work!! I know there are workarounds and I have used them but it would be much easier.
On Windows, you can define environment variables that auto expand to known directories. There are some variables that are already defined by the system. For example, %TEMP% automatically expands to c:\Users\<username>\AppData\Local\Temp OR WHEREVER THE USER MOVED TEMP DURING INSTALLATION. That's the important part .That makes it possible to write %TEMP%\abc as a symbolic path that works regardless of how the system gets reconfigured.
Users can define their own environment variables, and those get expanded when used in a path in the command line or Windows Explorer (the text entry region at the top of an Explorer window). On Linux and Mac, it is the equivalent of using $VARIABLENAME/abc, where VARIABLENAME is some user-chosen name.
[admin edit] Added background information on environment variables, and updated title to use the word "Environment" instead of "Environmental".
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.
How you ever had to design a SQL query? Probably
Usually I design these in MS SQL Server Management Studio, because its easy to test there. And I like that the sql code is colored, so its easy to see whats going on.
However, when I copy it into a string constant, the colors are gone:
But I noticed, that if I copy sql code into a mail or a document, the formatting from MS SQL Server Management Studio is preserved.
That is because the program stores RTF (rich text format) information on the clipboard.
Wouldnt It be nice if there was an 'Paste Special' or Quick Drop feature that preserved the RTF formatting when pasting text into a string constant or a documentation label?
Then it could look like this:
If you think that this could be a nice feature, then kudo this idea
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.