Why is "Rearrange Cases" not an option for a Case Structure with two cases? This page (http://zone.ni.com/reference/en-XX/help/371361H-01
I have a suggestion about Automotive Diagnostic Command Set. It is currently designed for CAN-based diagnostics only and diagnostics on serial lines (K-line and L-line) are not in the scope of the Automotive Diagnostic Command Set.
I would like the Automotive Diagnostic Command Set to support diagnostics on serial lines (K-line and L-line) too.
Automotive Diagnostic Command Set User Manual
When a control is disabled, especially a large table or string control, it would be nice if the scroll bar would remain active in order to view the contents of the control, without the ability to actually change it.
I am not asking that the default behavior be changed, however a right click property/property node "scroll when disabled" would certainly have some value.
I sometimes delete controls from the BD and realise some time (from milliseconds to minutes) that I have some broken local variables.
I get greeted by the hugely informative imagery as shown below:
Yeah, good luck realising what exactly you deleted by mistake. No name, no way of finding out what the local PREVIOUSLY linked to.
I suggest retaining at least the name of the Control / Indicator the local was linked to so that the poor programmer (me) has some fighting change of undoing the error. Bear in mind there could be many changes made to a VI before this kind of thing is notices so a simply "undo" fix could end up being VERY awkward indeed.
An example of how this could look:
Here I at least know WHAT I have deleted by mistake.
Since most (if not all) controls and indicators can be moved around with "position" property node programatically, the X and Y coordinates on the front panel are useful information to have.
As of right now, users have to adjust the position values by trial and error to know what values suit the UI, or maybe make a program to capture the mouse position programatically.
So I've been getting feedbacks from customer about a function where one can view the coordinates of the mouse all of the time. (meaning no programming is necessary)
I was thinking about two methods (see attached)
1. Show coordinates along with the mouse
2. Show coordinates at the bottom of the pane
I am getting tired suggesting small ideas that could all be placed under one single umbrella:
Any right-click option should also be available from the properties dialog of the item!
Here are some recent example
But there are probably many more....
Consider a distributed program, where client PCs have GUIs that show the values of variables hosted on the server PC. Suppose the server has to change its IP address.
Bind the indicator to a Network Item (hard-wiring the address of the server)
You'll need to update the server address in every single indicator
Write extra code to read the server’s address from a config file, and programmatically do the data binding
It’s extra code
Bind the indicator to a Project Item, and assume that the “My Computer” target refers to the server. Update the server address by updating the .aliases file
The client PC can’t have an alias of its own
Have separate targets for the Server application and the Client application (each target can have an alias). Bind Client indicators to project variables hosted on the Server (no extra code required). Update the server address by updating the .aliases file (don't need to update each individual indicator).
The Desktop Execution Trace Toolkit (DETT) can trace enqueue/dequeue operations, so I would think this is feasible:
Add a mechanism to like the Profile>Performance & Memory view to display all active queues in memory by name (for "unnamed" ones, use whatever unique refnum/identifier is available) as well as the max size and current # of items in queue. You could use the same "Snapshot" functionality as the Profiler tool.
A particular use case:
We were tracking a memory leak in a large application that resulted from an unbounded queue whose consumer was disabled. The standard DETT and Profile tools weren't showing where the excess memory consumption was coming from, since queue data does not "belong" to a single VI. Granted, you can see the individual enqueue/dequeue operations in DETT, and even highlight pairs, but that's a little cumbersome in a large application.
I would like to have the ability to make a Front Panel background transparent without making the whole window transparent (where the later is currently possible through property nodes). This one item would expand the UI possibilities. It would allow for the creation of Front Panels that seem to be borderless similar to many splash screens, about screens, and gadgets. Below are some industry examples:
Adobe Splash Screen (No border, has shadow, not square)
Microsoft Word 2010 Splash Screen (No border, rounded corners)
Resource Meter Windows Gadget (No border, specialized graphic)
Windows Media Center Gadget (Empty-transparent space between two UI elements)
I would like to see the context sensitive help window intelligently move out of the way of wiring. It frequenty jumps to the place where I need to run a wire. My idea would be that if the mouse cursor reached the edge of the help window it would jump to a remote place on the diagram, and if you happened to wire to that remote place, it would keep on jumping out of the way.
When debugging (and at many other times), I want to copy data from a probe or control into a text file, Excel, whatever.
For reasons that I am totally unable to fathom, it copies the control as a bitmap. Print screen provides this functionality already. I think copy data should copy text instead!
I wasn't able to find this on the exchange, sorry if I missed it!
When you want to make a resizable front panel there are only few possibilities, especially if you don't want all your front panel beeing resized.
Splitters are great but you can't always use it, in a tab control for instance it's impossible (and someone already suggested this idea here, sad it's not implemented ).
You can do it programmatically (lot of work!), maybe with an XControl depending on your application (lot of work too!) or you can also Scale Object with pane with only ONE object.
There's still one option: Scale all front panel objects when resizing
Why not improving this method by adding an Ignore Resize property?
It might be easier to implement for developers compared to modifying tab control and would be really easy to use !
Renaming files with F2 or the context menue entry "rename" is easy - as long as the file is a LabView or NI-File. But if it is just a simple *.txt, *.pdf, ... file it is not possible. Please add this function! - thanks.
As seen here, the property pages are sometimes like swiss cheese, i.e. full of holes! Useful and often-used properties are missing, even though they are available via right-click.
One example is "Loose Fit". There is no logical explanation why it has been omitted from the scales property page. I suggest to add it!
Here's how it could look like:
IDEA: Add "Loose Fit" to the property page.
I think it is very difficult to make a UI that runs on Windows and interacts with targets. Here are two suggestions to improve this:
1. We currently can't have \c\ format style in a file path control on windows. It would be nice to allow user to specify the OS syntax to use instead of assuming it should always be the local sytax.
2. The icing on the cake would be to have the File Path Control support a property node for an IP Address so when the user clicks on the browse button, it automatically browses the target (this is already an idea mentioned in the link below) and uses the syntax of the target. This becomes especially useful as we start to have targets that may have an alternative way of browsing files besides FTP. It would be a pain to figure out which SW is installed on the target and use the correct method to enumerate files/folders.
These two features could be implemented by having an enum property node for the File Path Control called Syntax which include options like: Local, Various OSes (Windows, Linux, Mac, etc), or IP Address. If IP Address is specified, another property Node called IP Address will be used to determine what target's OS to use (if it's not specified or invalid, we default to Local).
Parallelisation of loops is a great thing in LabView that offers a lot of possibilities and it's very easy to implement. In opposite to this debugging can drive you crazy regularly. A typical situation for me is that there are two loops in parallel whereby the first waits for user input (and handles it) and a second one cycles all the time doing some other stuff.
Assumed that the one with the user event handler needs to be debugged I place a break-point on a good place. When the execution stops there, I usually want to go step by step through the code. The problem is now the 2nd loop: because it is running in parallel the execution pointer jumps always between the two loops. I have to step through each function of both loops even that I only interested in the first one.
This becomes very annoying, confusing and time consuming if there is a lot of code in the 2nd loop, if the diagram becomes larger at all and if the highlight mode is activated.
To avoid this I suggest to show optional elements for debugging for each loop. With those elements I could decide if I only want to step through the code of the first loop while the second is executed normally (no highlighting, no single step).
With the increasing size of the LabVIEW ecosystem, there is a growing number of third party tools written in LabVIEW that are versioned independently from LabVIEW's version number. For example, I could create an API that has versions 1.0, 2.0, and 3.0, and all three versions could be compatible with LabVIEW 2009 or later. Tools like VI Package Manager make it easy for content creators to publish multiple versions of an API, and for users to upgrade and downgrade between those versions. However, this ease of use disappears if significant changes have been made to the VIs in an API, such as:
If any of the above changes are made to VIs in an API between versions, it can become impossible to migrate code between the two versions without a lot of manual searching, replacing, and relinking.
LabVIEW should provide a mechanism to define mappings between old and new versions of third party toolkit VIs. Consider the case where I make the following changes to a VI from my toolkit:
I should be able to create a mapping file included with version 2.0 of the toolkit that describes the changes made between versions 1.0 and 2.0 of the VI. This way someone could write an application that calls version 1.0 of the VI, then upgrade their toolkit to version 2.0, and the application source code would be able to find, load, and relink version 2.0 of the VI without any hassle.
The specific issue I've run into is that some newer LV features (like Auto-concatenating loop output tunnels and the expandable Merge Errors node) can be represented in earlier versions of LabVIEW with a more complicated combination of nodes and wires. When "Save for Previous Version" is used, the equivalent code needs more diagram space, but ends up all crowded together on the block diagram.
Here's a specific example (sorry I don't have the original LV2012 source):
In this case, the empty array constant is actually connected to the shift register input of the loop that it is placed on top of. This is completely invisible, though, and very difficult to decipher. In my case, I tried to move that seemingly disconnected constant out of the way and inadvertantly broke the VI beahvior, because the wire was disconnected.
I've encountered this issue in particular when receiving support from NI Application Engineers using LV2012 who build sample VIs for me to test and then need to down-save them for me in LV2011.
I propose that the "Save for Previous Version" automatically clean up the diagram for any nodes that needed to be changed/added in the down-save process (specifically to avoid overlapping and confusing nodes).
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.