Allow the configuration portion of DLL nodes to see mangled function names, such as those generated by many C++ compilers (@Initv, for instance).
Invoke nodes can have lots of optional arguments, resulting in their taking up a lot of vertical space. I would like to recommend that the arguments portion of Invoke nodes be resizeable, allowing the developer to select the optional arguments to be displayed on the block diagram and, hence, have more control over the layout of the block diagram.
Consider the Save-As Invoke node from Microsoft Word:
which gets longer with each new version of Word.
Now imagine being able to show just the optional arguments that are needed:
And, as an added bonus, this Invoke node would not break when the VI is opened in a development environment that has a different version of Word with the same exposed optional arguments.
When a control caption.text property is called and the caption has not been set in the Properties dialog of the control an error is thrown.
It would be nice for the caption.text to default as an empty string so an error wouldn’t be thrown when it is called in the block diagram. This would allow easier runtime editing of each control on the VI.
When you map a control on the front panel to the Connector Pane, you do not have control over whether it is Required or Recommended. There is a default set in Tools>>Options that defines this for all new mappings. However, it is extremely common to want to specify something different than this default. To do this, you have to make the mapping, then right click the Connector Pane terminal and reconfigure the requirement settings.
I propose that we cut this two-step process down to one. If you select an empty Connector Pane terminal and then Ctrl-click on a Front Panel control, then it should be mapped as Recommended.
This allows users to set the default mapping behavior to Required (which is the best convention), but then map optional control inputs in just one step instead of two.
This Ctrl-click would not conflict with swapping Connector Pane terminals, because you are not clicking two Connector Pane terminals, but rather one and a Front Panel control. However, to avoid confusion I could envision Shift-clicking or Ctrl-Shift-clicking.
I suppose this is a grey area between feature and CAR, but it is certainly a long-standing aspect of the LabVIEW editor that vexes me on a daily basis that could be improved.
The issue is that if you are dragging to select objects on the block diagram or front panel and you accidentally move the mouse cursor to the edge of the window, LabVIEW starts scrolling insanely fast in the direction of the mouse. By the time you've figured out what's happening and released the mouse, you're often 4-5 screen lenghts away the actual content of the diagram, and you must now manually scroll back to the main area. To make things worse, you're not really sure where the origin is anymore, so it takes a little blind searching to find the screen contents again. In addition, you're likely left with a selection that is not what you intended, meaning you have to start over (more carefully) from scratch.
I really don't see any reason to scroll the panel so terribly fast. At all. A slow, steady scroll, in my opinion, would always be preferable, since the fast scroll leaves the user no real control at all over what's being selected. If anyone really wants a chaotic super-fast scrolling operation to be preserved, I would perhaps accept a shift-drag option to enable this.
The difficulty with documentation and assistance provided by experts and veterans, especially on forums, is that the code supplied is poorly annotated, e.g. in examples posted, VI name labels are usually not turned on.
Because of the thousands of VIs supplied by National Instruments, I doubt anyone can identify them all at a glance.
It would be a great service to new users or users expanding into new functions to be able to:
Screen capture an icon (or group of icons, if possible) or provide a PNG or JPG file and pass the file to a utility which would identify the matching VI by name or show close matches.
Nothing is more maddening than seeing a solution to one's problem without being able to identify the VIs used.
Working in an GxP environment in the pharma industry, any initiative to make NI software products more compliant with the FDA guidelines would be most welcome. One such relatively simple measure would be to enable "sealing" of TDM files, such that any tampering with the data is either impossible or logged.
I believe I have passed this idea on to NI several years ago and I apologize if it has been implemented already.
Cygnus Data, Göteborg, Sweden
The built in dialog boxes (such as one button dialog) in LabVIEW are set to the 13pt dialog font. It would be very handy to be able to set the font size, bold, color, etc. for a dialog box. Some of my applications need a pop-up that is easier to read, so I have to make a custom dialog box in order to change the font size.
There are many properties that have equivalent event terminals. Unfortunately, they are often named or typed slightly differently, creating lots of coercion dots for no real good reason.
(I've run across many more over the years, so this is a very incomplete list. Feel free to post other cases here )
For example (property vs. event terminal)
Active cursor (U32) vs. CursIdx (I32) (why U32 vs I32?)
Cursor.position (Cursor X, CursorY) vs. CursLoc(X, Y) (example from here)
(note the coercion dot on the event output tunnel)
Add the Legend index as a Read/Write property for graphs. This will give the programmer to option to programmatically change what is displayed in the plot legend, as well as changing other areas of the user interface based on what is displayed in the legend.
deI would love to change the size of the view window only with the scroll mouse, specially with large programs, both in block diagram and front panel. In the block diagram for better control of the code and in the front panel for more quickly structure and design.
It would be very helpful for the programmers if the controls/indicators properties window has one more tab where we can define conditional expressions for disabling enabling the controls/indicators instead of writing case structures in BLOCK Diagram.
I often want to add VI B to the block diagram of VI A - and they're both in the same project. I'd like to right-click on A's block diagram, and choose "Selects a VI..." that shows me all the VIs in the project. I also want this feature to work for classes, lvlibs, etc... I also want this for the front panel controls palette too. I'm not asking for too much, am I?
I don't like that controls, type defs and strict type defs all have the same file extension: "*.ctl". I'd like to see something like:
(I don't think there needs to be two extenstions to distinguish between type defs and strict type defs).
I am a user of Gmail and they came out with a great feature I think could be applied to State machines
They use nested labels. If you type in the following you can have a "Folder" Test/Init.
Using this concept I think you could easily add "folders" to your state machines. You could group like states easily. The case structure would recognize the "/" character and group and indent appropriately.
Looking at messy diagram from forum posts (not mine!), I often find myself in a situation that I cannot really tell where an "interesting" wire is coming from. Triple-clicking just shows me a spiderweb of wire segments going in all directions.
Often, the leftmost wire end is near the data source, but not always. Maybe it would help if we could right-click on a wire and do a "find source" and a halo,(or donut or similar) would temporarily appear showing where the data in the wire is originating.
A wire can have many sinks, but only one source and the data source is the most interesting property of a wire.
A tool to find it quickly could be helpful.
This picture is way too ugly, but should give some idea....
I wonder if newly created wire labels should inherit the wire color for better clarity. Labels on array wires (and other thick wire thingies, clusters, objects, etc) could go bold for the same reasons.
(Of course the programmer can later freely change these label text properties)
In the world of tab controls, a tab caption refers to the actual text in the tabs that you click on to select the different pages, see attachment "Tab Caption". Currently, there is no property node that allows you to change the font characteristics of the tab captions. The font characteristics can be customized non-programmatically by right clicking on the tab control and selecting Advanced/Customize. However, within the customize control all the tab caption properties are linked, so if I make the font color red for the page 1 tab caption, it will automatically change the page 2 tab caption text as well, see attachment "Customize". The same thing applies for the other font characteristics.
This functionality would be useful for those users who want more control over the aesthetics of their front panel. For example, if a user wanted each tab to represent a test that he was running he could change the individual text and color to represent whether or not the test passed, green "passed," or failed, red "failed."
If LabVIEW shows coercion dots, I usually insert the corresponding conversion function (as recommended).
Some times it is a little bit annoying to seek the correct function. Especially because I know that LabVIEW knows the desired data type. If I connect the wire to a VI I have to look up the correct type in the context help. Afterwards I have to seek and insert the corresponding conversion function.
I think that LabVIEW should support this replacement a little bit more.
I suggest an interactive support:
a) If you click on the coercion dot LabVIEW should show a little dialogue and suppose to insert the corresponding conversion function.
b) If you right click on the corresponding wire the context menu should purpose the corresponding conversion function more directly (see pictures).