When you align a control that has increment/decrement buttons to other objects on the front panel that do not have them, LabVIEW aligns the buttons with the edge of the other controls. The align objects command should ignore the increment decrement buttons and align the border of the control with the borders of the other controls.
Workaround: Hide Inc/Dec Buttons, align objects, Show Inc/Dec buttons. However not as convenient.
When I use array constants on the block diagram I often expand them to show how many elements they contain - I even expand them one element further than their contents to leave no doubt that no elements are hiding below the lowest visible element:
Often it's not so important to know how many elements are in the arrays, nor even their values (one can always scroll through the array if one needs to know). But it can be very important to not get a false impression of a fewer number of elements than is actually present, for instance when auto-indexing a For-loop:
To be able to shrink array constants to a minimum size while still signalling that they contain more elements than currently visible, it would be nice with an indicator on the array constant when it's shrunk to hide elements (here shown with a tooltip that would appear if you hover on the "more elements" dots):
The information in the tooltip would be better placed in context help, but the important aspect of this idea is the "more elements" indicator itself.
Once in a while I complain about font issues in general (here, here, or here), but one of the really weird things are the font sizes as used in LabVIEW.
The font dialog lists them as units of pt, but for some reason they are quite different in size from the same sizes in any other applications (browser, word, etc.). LabVIEW also shows other problems, for example tahoma 14, 15 all look exactly the same... why??
Here is a side-by-side comparison of a wordpad document and a LabVIEW panel. Each line is configured for the indicated font size.
As you can easily see, LabVIEW is the exception. Any other applications I tried agrees with the left panel.
There are times when I leave a VI with modal properties open and then I run the main application that also calls this VI if opened in the development environment. This locks all running windows due to the modal VI. I propose a button in the taskbar that aborts all running VIs OR perhaps a list is opened on right-click of all running VIs 🙂
I use the conditional disable structure in my projects to turn debug options on and off.
At the moment before every build I have to go into the project properties and make sure that DEBUG variable is set to FALSE and after the build I have to change it back.
You can get around this by automating you build but an option in the build specifications would simplify this.
It would make life much more convenient if there were a list of the available (non-system) conditional disable symbols in the application builder dialog where the appropriate variables for the build could be set. This would also allow for a simple duplication of a build spec to have one with DEBUG=TRUE, and one with DEBUG=FALSE.
I've been doing a lot of string comparisons lately and I really hate having to drop To Upper/Lower Case function in front of my Equal? comparisons, as shown below:
It would be so much nicer if I could just have a special Case Insensitive mode for the Equal? node (and, it would be nice if the Equal? function changed its visual appearance, somehow, to signify that it is in a Case Insensitive mode):
Oftentimes, rearranging or reordering a Bundle by Name or Unbundle by Name for clusters can yield fewer wire crossings. For instance, below, wire crossings can be eliminated by moving "Timestamp" to the bottom of the Unbundle and "Value" second to bottom on the Bundle:
The current process of moving one of these elements:
Increase the size of the node using the Resize Handles on top or bottom, or select "Add Element" from Context Menu (and hope you remember if it adds and element below or above the cell you are clicking on!
Wire to the new element, and deal with deleting the old wire
Delete the old accessor using either Resize Handles or "Remove Element" from Context Menu
This can be laborious. Instead, I would like a way to quickly reorder the elements. I have a few ideas how this can be accomplished:
Context menu with a "Move Up" and "Move Down" action (not so elegant)
A pop-up window that allowed rearrangement (think "Rearrange Cases..." on Event Handler or Case Structures)
A native drag-and drop on the Unbundle/Bundle node itself. This could be realized given the current "click regions" on the node (hover your mouse and sweep horizontally over one of these nodes... you'll discover the 4 regions). The two "Arrow" regions currently move the node on the BD, but they could be used to rearrange the node (see below)
Just throwing out some ideas, I'm not stuck on any one. So, the idea you are voting for: Provide a User Interface for quickly rearranging elements on a Bundle or Unbundle by Name.
There seem to me to be a couple of choke points in right-click access to VIs and functions. One is that I frequently need to use the same VI's repeatedly. Another is that the quite useful "insert" and "replace" context items only offer a few first-tier options: one or two related palettes, or all palettes. Try to insert a few datalog functions for example, and you have to navigate down 6 levels for each. It's even worse if you have to use "select a VI..." and browse to it. For the worst cases, insert and replace lose their advantage over copy-paste or quick drop.
I propose a dynamically generated palette consisting of the last several VIs and functions (even controls) that have been dropped. This is analogous to recent-commands-list functionalities common in CAD packages.
- As a member of the functions palette, the items in it are at or above the level they are in their normal place in the hierarchy.
- Since it's a palette you could pin it and it would be handy for dropping the same node on two different block diagrams
When wiring a numeric or enum to a case structure, we get the existing case as 1 (or the second enum item) and a default case also containing "0" (or the first enum item). Many times we need a special case only for one item and everything else should be in the default case.
Case structures are happy with just the word "default" in the second case. The unfortunate automatic existence of one other specific selector value in the default case hampers workflow. For example in the vast majority of my coding, I want the special case to be zero and the other case to be the default.
After wiring the selector, I could just enter the desired value in the non-default case that is showing, except if that desired value also exists (for no good obvious reason!) in the default case. If this happens, I need to edit the default case. That should not be necessary.
Suggestion: Whenever a default case is automatically created, it should not contain any extra specific selector values.
Although the suggestion about using a template is quite nice, I would still like to be able to create a new VI (or sub-VI) from within a project. I never use the default icon provided by NI. -- N-E-V-E-R -- That's a personal choice.
So since I never use that icon, the fact that creating a new VI which auto-generates an icon that is never used, renders that feature useless. Let's see how many users of LabVIEW also find the default icon useless.... (Kudos would be a way to take a poll).
A nice feature would be to allow the developer to create her / her own default icon. The default icon is probably somewhere in the ini file (I have not checked). One of the Options could be to select if the user wants to use their own default, and if so, browse to the icon or have an editor create one.
In my case, when creating a new VI, it ends up with a icon like this:
I would be happy to have a default icon that looks like this:
The idea I am proposing is that developers should be able to have the icon of their choice as a default icon.