If I have a path control on my front panel for the user to interact with, I will always show the browse button. This button makes selecting a path easy from a user perspective, and from a developer I know that the path they selected has some level of validity. So for instance I know that the path they selected must exist and be a valid path otherwise Windows won't let them select it, and the value change won't be triggered for the control.
But the user can manually type in text into the path control, and when focus is taken off the value change event will take place. The problem with this is the path they entered might not be valid, or may contain characters my platform doesn't support.
I doubt a user will manually type in text in the control often, they will use it as an indicator showing the path they selected using the browse button, but on the off chance that they type somthing and it isn't valid, my code might crap out throwing errors.
I can add code to check for a valid path, and I can add code to check for illegal characters in the path, but I'd have to do this for every path control on every UI the user sees. I could also write an XControl for this with a decent amount of work and hopefully meet my needs, but it would be nice if this were a native feature.
So what I'm suggesting is that the path control have an option, possibly in the browse options dialog, which makes the interaction with the control, only available by using the Browse button. This would ensure that any value change event will be from the user picking a valid path with the browse button.
I faced to delete multiple elements form the array which is having 20 steps.
if able to select multiple elements by holding the shift key we can delete selected items 1 time and can insert 1 time.
I have a large library of general purpose functions and I do a lot of OOP in LabVIEW, and as a result my preferred workflow involves dragging a lot of functions from the project explorer window onto the block diagram. This workflow is slowed down, however by the fact that the project explorer window is regularly hidden by other windows when I click on them.
What I would like to see is something like most development IDEs have, e.g. Visual Studio, where I can have the project explorer always visible in a fixed position on the screen. I suggest this would be an option, so would not affect those who like things the way they currently are.
I just had a case today where I had an existing wire (An array of configuration parameters) and I selected the wire and then tried "Create Sub-VI" on it. Nothing happened.
Perhaps it would be simply consistent behaviour if we then allowed creation of a simple VI with Wire Datatype in and out with input terminal connected to output terminal.
Should be able to specify tolerance instead of just upper and lower limits. This de clutters the application block diagram when you are checking for a value within certain limits.
. Upper limit becomes : x+ tolerance, Lower Limite becomes : x - tolerance when using tolerance instance of the polymorphic vi.
For even higher level functionality , specify units of tolerance : absolute, percent(1e-2), parts per million (1e-6), parts per billion (1e-9)
Say I paste a function down inside some structure, say a case structure. I wire from the input of the function back to the left hand border of the structure, which creates a tunnel with a 'broken' (dashed) wire to the function.
I would like to be able to right click on the tunnel and hit 'create control' and have it work. Although the wire is dashed, there's no ambiguity about the correct control type as it needs to be the same as the function input.
I use Splitter extensively to create resizable GUIs. However, if I create my resizable GUI and then my customer asks me to add parameters in a new pane on the left, I can't add to an existing GUI a splitter in the top of the hierarchy, i.e. a new vertical splitter that all the existing splitters will be on the right of the splitter and a new empty pane on the left. Any splitter I add will be added to the bottom of the existing hierarchy, and there is no way to change this. So to do this I basically need to rebuild the GUI again from scratch.
Another example, if this is my GUI:
I can't add a status bar now, as any horizontal splitter I add will be inside an existing pane, and this can't be modified. However, if this idea were implemented, I could View splitter hierarchy and create a new horizontal splitter at the top of the hierarchy so that I would have my status bar without rewriting the whole thing.
Picture says it all.
I am not allergic to Kudos, in fact I love Kudos.
Make your LabVIEW experience more CONVENIENT.
When first launching the Quick Drop tool it can take a while. This isn't a problem in itself, but the fact that you can cancel the loading or continue working in the background is. This is especially annoying if you launch it by mistake.
Not a major thing, just something that could be improved.
NI send us the NI Developer Suite each year on DVDs all packed in a nice little NI branded dvd carry case. We are on the SSP suscription and we receive 3/years, which means I have a whole stack of them.
I suggest that NI start shipping USB keys instead. USB has several advantages:
If you have made a custom run-time shortcut menu and saved it as part of the control (always necessary for applications due to this issue), it is currently way too easy to lose that menu. If you replace the control, even though it is with the same type of control, the menu is silently lost. So if you have made right-click shortcut functionality, the user will no longer be able to call that funcitonality.
a. As a minimum you should be warned that the control you are about to replace has an embedded shortcut menu.
b. The warning could give you the option to copy the menu to the new control (OK set as default), or
c. The new control could automatically inherit the original's shortcut menu
d. -Alternatively only if of the exact same type (if you for example replace a modern styled listbox with a system style listbox).
I would prefer alternative b, as it would draw the developer's attention to the possible issue of the embedded menu (perhaps it is *not* wanted anymore, perhaps it is...), but make it quick and easy to choose to keep the menu (most frequent I would guess).
In the project explorer, dragging an item into a folder opens that folder AFTER the drop. This is annoying. But I digress...
In fact, what would be useful is to have the behavior of the two file explorers I am familiar with (Windows and Mac OS), that is:
- if an object is drop onto a folder icon, the folder does not open (see link above)
- if the object is held for a while over the folder icon, the folder opens
This is particularly helpful if the project explorer has a hierarchical structure of Virtual Folders:
If I drag Untitled 1.vi over the Action folder and hold it here for ever, nothing happens, and in particular, I can't access any of the the subfolders.
After dropping it, I get this:
Now the top folder is open, but the VI is nowhere where I want it to be and I need to repeat the drag & drop action.
This example doesn't do justice to the real issue which is that for large lists of VIs and folders in a project, this becomes a real problem, as VI and target folders (after everything is opened to provide a clear path from original to target destination) may end up separated by large amount of space in the project explorer and you now have to use the temperamental "Drag the object over the 1-pixel wide location at the top of the project explorer to trigger scrolling" feature in order to slowly bring the object to its remote destination.
If you need to wire cross other wires it would be nice just for the optic to have the error wire always in the background of the cross. Now the wire which is connected first is in the background and all other overlay it.
When creating a state machine it's often handy to use an enum that lists all your states.
You then take that enum and make it a type def so that if/when you update the enum (to add or remove a state) throughout the states, all instances of the enum get updated.
But the thing is, now this potentially simple state machine VI requires this secondary type def file. No other VIs would need access to this type def so making it a seperate file just shouldn't be necessary.
In addition or extention to this idea
I would like to have a transparency control/property in the colour selection for plots in graphs and charts.
Have the quickdrop catch the keyboard shorcut keypresses while it is loading the list.
At the moment my VIs keep trying to run becuase I've pressed Ctrl+R quicker that quickdrop has loaded the list in.
On all LabVIEW version, we can use Formula node to evaluate mathematical formulas.
We can define input and output variable freely and calculate using some variety of formula.
But when we use undefined variable as output, can execute VIs with no errors.
We think it is a problem because when programmer makes a typo, they cannot notice the mistake.
When undefined variable is used as output variable, LabVIEW should forbid to run VI.
The various instances of the polymoprhic XML Close VI all have standard error in functionality. In other words, they run normally only if no error occurred before they run. That can lead to references not getting closed if errors occur in sections of code that execute earlier.
Instead, the XML Close VI instances should run normally even if an error occurred before they run. When calling the XML Close VI, it is a nuisance to have to clear the error passed in to it and then merge the previous error with the error output from the VI.
In addition, most of the other Close functions and VIs in LabVIEW run normally even if an error occurred before they run (Close File, UDP Close, VISA Close, Close Reference, DataSocket Close, etc.).
There may be other VIs and functions that have the same behavior as the current XML Close VI and they should be changed as well. Examples include TDMS Close, Close Zip File VI, etc.