(Unless it's already changed in newer LV's, i'm on 2011 right now)
When opening the connector pattern, the current isn't marked in any way. If i'm after some extra connectors or a symmetrical one (why do people choose 3-1-1-1?) it'd be nice to quickly see where to start looking. A simple bold outline would suffice, maybe in blue?
I am taking advantage of the recent FileVersionInfo to pull up the Version Number of the Executable at Run Time and display it for the User (who can then call me and say "Version 184.108.40.20634 crashed", and I can figure out which source this was). I take advantage of the Pre-Build Action to create the Version Number, taking the "Build" part from the Revision Number of the Project itself (since the Pre-Build Action gives me the path to the Project, this is fairly straight-forward).
However, in order to get the correct Build to appear in my Executable, I must build twice. The reason for this is that LabVIEW apparently reads the Version information before executing the Pre-Build Action, so my attempt to set it to the "correct" value is ignored until the subsequent Build.
Personally, I think it is illogical to have a "build Action" that silently takes place before the user-specified "Pre-Build Action", though there may well be a hidden "good reason" for this. I would like to request, therefore, that LabVIEW include a "Feature" that specifically allows the Pre-Build Action to include not only setting the Version Information (which it currently does) but allowing this updated Version Information to be used in the current Build. True, the work-around of "Build Twice, Use Once" works for me, but why should we need to jump through this particular (unpublished and unexpected) hoop?
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.
"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).
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).
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.
It is always great practice to make your code as readable and scalable as possible, along with good documentation. One of the things that get overlooked the most, without even realizing, is having coerced inputs to your functions or VI's. When you have finished developing a program, it goes through a great deal of review to validate all its functionalities. Coerced inputs can be one of those issues that can come back to haunt you down the road. I think having an icon on the toolbar and/or a shortcut keystroke to populate a list of all VI's containing coerced inputs would be a great help with identifying all the necessary functions that need to be examined.
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.
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.
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.
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.