I have the hadit of pressing Ctrl+Shift+S (Save All) which is annoying while working with Read only VIs. We always get a pop-up enabling us to save the VI in a different place or with a different name. As a result we get the browse window to Save the VI with a different name or in different path. This happens on clicking OK (which make sense) but also on click Window close button/ESC key.
My suggestion is to continue the save operation only on clicking OK and abort the operation when the user click the window close button/ESC key. This would be more meaningful and would make more sense to the way the Save operation is handled.
I am also fine with adding a Cancel option along with the OK button.
How the ideas exchange has existed for more than one project for anyone and not had a datagrid added already is beyond me. LabVIEW's table is horible, they need to add a proper grid, similar to flexgrid or other common web grids, that has grid sorting, grouping, sortable columns, drag n drop orders, totals, cell editing, cell binding, cell data types, binding complex objects (clusters), themes (CSS formatting perhaps).
"Find Items with No Callers" could be a useful function on the project, but currently most items it reports are in Dependencies. Why is an item even under Dependencies if there is no caller? It seems if I call one function from an .lvlib the whole library is in dependencies, and all other functions have no callers. This floods my "Find Items with No Callers" window with useless entries.
Suggestion: add option to hide items from dependencies in the "Find Items with No Callers" window (or even hide them by default).
I would find it extremely convenient to have a notification option (or options) to notify the user when the Build Status for a project is complete.
Sometimes when building executables or installers--or both--the compiler can take a while depending on the size of the project. During this time I don't just stare at the progress bar, but found that even if I left window open in plain view (off to the side or something), it is not obvious when the process is complete (the 'Done' button changes to Enabled and that's about it).
Options to notify the user could be any number of things:
Looking at all my body of work, I use tables exclusively as indicators. They are well suited to display formatted results in tabular form, but much less suited for user input, because they only allow strings. If we need to enter numbers, there is no input validation (as we have e.g. for numeric controls), so they are pretty useless for that.
It is thus a bit confusing that the tables in the palettes currently exist as controls. In fact, the modern, classic and system tables are even labeled "Table Control" (seems redundant!), while "Table" alone would have been sufficient (this has already been corrected for the silver controls ).
It would be much more appropriate if tables are indicators by default. We can always change them to controls in the rare case where this is needed.
There are numerous ideas floating around about where the color box constant and control should be located in the palettes. How about if there wasn't a distinction between a color box and its numeric representation? Like the "View As Icon" option on terminals and clusters, I suggest a "View As Color Box" on numeric constants and controls/indicators:
I'm undecided on if this options should be available for all numeric data types, integers only, or U32 only, and what should happen to the Representation options when the numeric is a color box. I see at least these options (ordered after my preference - I prefer 1) the most):
1) The "View As Color Box" option is available for all numeric data types, but when selected the data type changes into U32. If you change Representation to anything else but U32, the "View As Color Box" option is automatically deselected.
2) The "View As Color Box" option is available only when the numeric is U32.
3) The "View As Color Box" option is available for all numeric data types, and coercion happens between the selected "color value" (U32) and the true Representation of the numeric.
When debugging, I often find I need to jump over a number of operations before jumping into an operation I'm interested in. It would be nice if we could mark VIs to not be entered (always skipped) when debugging, so that I can just spam the jump into key until I hit the one I want.
I like to collapse long string and path constants to consolidate diagrams. Showing the string or path value in the tip strip is useful but tedious to update.
I suggest an appearance property that would automatically display the current value in a tip strip for string and path constants.
This property would be most useful if the Block Diagram Options page was also modified to allow a global setting.
Cleanup diagram is not much used (Personally I allign the diagram myself manually). But if we have few improvements with the tool we can use it atleast in sub vis more often.
At present the Cleanup diagram tool introduces unncessary wire bends eventhough it can be avoided. So it would be great if this is taken care properly and unncessary wire bends are removed.
Manually alligned without wire bends
Wire bends are introduced once the Cleanup diagram is done.
One of the things that sometimes bugs me when using LabVIEW is that if you have a front panel or block diagram in a small window, many of the menu options and toolbar options are inaccessible without having to resize the window first. You have to have a minimum window size to be able to access all of the toolbar functions.
Still don't get it?
This is how big I want my SubVI window to be:
Problems with the above:
To be able to access the entire toolbar, the windows has to be at least one of the following wide:
Why is this a problem?
Please make it so that the menu and toolbar are accessible regardless of window size. One solution would be to have a button that allows you to 'scroll' the toolbar or have a pop-up dialogue that shows the missing toolbar buttons as per the image below.
MS Paint skills (icon lifted from Chrome's bookmarks bar):
As an aside, MS Word manages it fairly well (even though it isn't that readable), and it has a LOT of toolbar buttons:
Please consider my idea (or Kudos it) for future versions of LabVIEW - it will improve usability of the IDE.
Recently, I discovered an annoying "feature" of LabVIEW: if you limit the data entry of a floating point numeric to a maximum value with coercion enabled, entering NaN to that numeric will be coerced to the maximum that you set in the data entry dialog.
I already reported that as an unexpected behaviour, but after some more thinking, I dare to go even further and propse:
allow the blocking of NaN in floating point numeric data entry
The logic needed should not be much more than a finger exercise, as string controls already allay to discard CR/LF with the "limit to single line" property.
In many cases I need to use Empty String/Path array constants (Example: Initializing a shift register) but creating a normal String or Path is not readable on top whether anything prresent in the array constant. So it would make more sense to have an Empty Array and String constants available from the function palette. This can be created by pulling an Empty array and dragging the Empty String/Empty Path constants. In this case the Index and scroll bar selections from the view menu may be disabled.
The same can be extended to the other 2D array and further dimensions, which may be given polymorphic behaviour when wired to the respective dimension array.
During implementation of code, the algorithm and its implementation has to be tested and debugged in most cases many times. For debugging, probes are a very useful tool. But probes can only be created on existing wires.
If, for any reason, the developer wants to probe values which are not on a wire already (e.g. iterator of a loop), he has to create an indicator (or tunnel) in order to have a wire. Once the debugging is done, the terminal/tunnel and the wire should be deleted.
I find it would be much easier, if i could right-click the data output and select Create >> Debug Terminal. This terminal is part of the code, but once i close the probe, the items created by this option (terminal and wire with probe on it) are removed automatically.
PS: I know that there was a suggestion specifically for the iterator of a loop. I understand the reason why it was declined, but i find that using VI Scripting, the above mentioned functionality could be provided. As i WANT to have the information of that wire during debugging, i require that terminal/wire in any case. Using some automated tool would ease the debugging process with the hope to decrease time required to identify the software anomaly.
How about a feature in DETT that allows users to generate a plot of the memory allocations over time? This would be useful to diagnose memory leaks that occur over a period of days or even weeks? Currently it is difficult to draw conclusions from the details column unless the data is copied into a program that can generate plots.
This idea is somewhat similar to Shrink-Wrap-Structures but for comments and strings
The idea is to resize a comment or string to the text by double clicking one of the resize indicators around the box.
This would happen without changing the number of lines or words on each line.
The process would be resize the horizontal direction of the box until the line layout looks nice (and fits!) then double click the corner to remove the unwanted space.
There could be different resize processes depending on the corner or edge you click eg. double clicking bottom middle resizes to only remove vertical space, top left would resize and shift the text down and right so the bottom right corner remains anchored.
There are some other ideas about resizing multi line comment boxes but none were quite as straight forward as this so I made a new post for it.
This mechanism is similar to other programs for resizing boxes so it seems like a sensible thing to implement.