Right now, this doesn't work:
I have to add a Convert Units function to make it work:
It would be cool if the Wait (ms) function were polymorphic, accepting floating point inputs with "units" of time, and performed the unit conversion behind the scenes (and without any coercion dot).
Of course, this might require renaming the function to simply "Wait" (w/o "(ms)" qualifier).
Provide an option to display a QR (2-D) code in the product activation dialog. The QR code should contain a web address that would return the activation codes for all selected products. For those of us stuck out in a lab or factory with only our smart phones this would provide a slick, foolproof way to enter all of the data needed. It would save us from either making a round trip back to civilization (with a pad full of info) or getting carpal-tunnel trying to type all that stuff in on a little soft keyboard (multiple times for multiple activations = hand cramp). We would still have to type the resulting activation codes into the LabVIEW activation screen but that's a lot easier than all the rest.
1) Provide a http link as a QR code
2) Have the target web page auto-generate the activation codes and display them (preferably in a mobile browser friendly format)
3) As an alternative, let the user upload a picture with the QR code to the NI activation web site for the same result (works for anyone with a camera not just smartphone users -- this would also let you show off IMAQ.)
(And, once you have the QR-code generation code available, add a VI for it to LabVIEW -- see http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Gene
Currently on waveform graph, once a plot is named it cannot be deleted (it can be made blank, but it still shows in all pull downs). For instance I plot 3 graphs, each having 16 plots. I then refresh data and plot only on graph of 11 plots. My new plot names show in the top of the pull downs, but all the previous plot names still show up as well (see attached screen shots).
Please expose a method to remove plot names (property to give array of existing names and property to remove name or all names).
The Windows 7 file permissions in the Program Files directory are causing a lot of headaches, especially with *.ini files of existing applications. It would be nice if LabVIEW had an option where install file paths of these files could be set based on the system they are going on. For instance, if the installer is being run on Windows XP, the installer will know to put the ini files in <Program Files>\<App Name>\Config but on Windows 7 install the files to <User>\Local Settings\... or whatever we choose.
Right now it seems our only option is to build 2 installers and have a batch file decide which to run. Unless, of course, someone can tell me otherwise.
A new feature that would act similarly to the "Automatically close VISA sessions" option and close all open file references once the top level VI has stopped running.
This new function would preclude the situation where LabVIEW locks, and keeps a file locked until the entire development environment is closed.
(I would even be happy with a menu option to explicitly close all open file references.)
The primary use case would be during development/debugging. If you stop or abort your top level VI without closing a file reference, LabVIEW will hang on to the reference keeping it open, but inacessable, until the dev environment is shut down.
It seems that if there is not an open reference to the file on the block diagram or the top level VI has stopped running, and certainly when all open VIs are closed, then all files should be closed and locking handles should be released.
I suppose this concept could be expanded to cover any reference type that LabVIEW does not implicitly close when the top level vi goes idle.
Sometimes it should be nice to be abble to hide Splitters in the front panel editor, like a "Hide control/Indicator".
For example if you want to create autogrowable/autoresizeable applications you have to use splitters in order to use the "Fit control to pane/Scale object with pane" functionnalities. If the splitters have to be "Locked" and not moveable by users ... you can't completly hide them.
PS : I hate the completly hidden controls in edit mode . I would prefer to have such a kind of "Splitter shadow" during edition mode. In run mode the splitters will then be completly hidden.
The Undo (Ctrl-z) menu option is not available in stand alone applications built in LabVIEW.
The LabVIEW help confirms this: http://zone.ni.com/reference/en-XX/help/371361G-01
Look where it says: "Items followed by two asterisks (**) are available in stand-alone applications you build in LabVIEW."
Then look for Undo and Redo in the Edit menu and you will see that they are not followed by the (**).
I posted the code that I created to implement Undo for exes: http://decibel.ni.com/content/docs/DOC-14805, but I believe we should be able to use the "Application Tags" instead of having to create code for something that is already implemented in the Development environment.
I have pondered this and not sure it is possible but it would be nice to allow using case structures to work with vi server references. It is very tedious to test each type with a cast to more specific and the for each type and check for error (current method or itterating through the class hierarchy).
I know that subclasses pose an issue, I would like to see for the case structure to limit each case to select the highest level (ie g object) and the distince cases are error or any direct class child of the specified parent type class.
The Use case I see is for handling itterating through controls from an array of controls (if the control is a boolean do something different than if the reference is to a string control).
Could be very nice for scripting.
For Reports it is only possible to set one with for all columns. It would be nice if the polimorphic VI "Append Table to Report.vi" would support column with for multiple columns too. Several VIs would have to be copied and adapted.
For a standard report, the VI replacing "Set Table Column With.vi" would look like this:
The functionality to adapt to the page with if the column with is too big is lost when different withs are set. But probably NI could fix this too.
Expose a method to set the scroll position of the plot legend for graphs, charts, etc. I often want to operate on multiple graph sets containing multiple plots, (i.e. multiple files each containing multiple plots). I overlay these and align them for comparison. It would be nice to be able to set the plot legend scroll position so that the active graph set is visible in the limited screen space I have for the plot legend. I also typically use a Boolean array along side the legend to set visibility for each plot. If I could scroll the legend, I could keep things aligned and have to do much less data manipulation to track the other plot properties when I bring an active file set to the top of the list. An example GUI is shown in the attached file.
Many times I have multiple states in my type def enum control. When I edit enum items I would like to see bigger window for better item control. There is lot of empty space on Enum Properties: window but you can't expand Item window at all. Or the window could fill whole applicable space by default.
This would be nice to have option.
Often when using tables (and multicolumn listboxes), the content of the table column or row header is longer than the desired width of the cell. It would be nice if there was an option to make the contents of the cell wrap to the next line, similar to how tables work in Excel or Word.
Also, adding vertical justification options such as Top, Center, Bottom to the Active Cell property subset would be nice.
Here's a crude illustration of what I'm talking about.
Maybe there is a very good technical reason why this idea is not a good one.
Problem: If I want to load a vi into my application the subvi's of the dynamically loaded vi can not be found.
Solution: Add a boolean input (or an options flag) to Open VI Reference which will load the vi and modify the search path so the subvis can be found.
I know there are several workarounds but I would like this to be easier.
This is something a few power users have asked me about. There's no Instrument Driver or VIPM Idea Exchange, so I thought I would post it here.
What if VIPM could manage Instrument Drivers from IDNet?
There are a few key benefits this would offer us...
There is a long standing omission in the refnum palette of the synchronization and event refnums primitives. The new and popular DVR ref should also be added. My example here shows these oft used reference controls at the top of the palette, where I think they should be. While I don't have the rendezvous in my example, it should probably be added as well, even though I don't personally use it that often. In summary, we shouldn't have to do the "create control>cut>paste" shuffle to get the notifier/queue/semaphore/rendezvous/event/data value references. Sorry if this is already posted. I searched on refnum palette and didn't see it.
Create an easy way to go back to the previous view you had on the block diagram. Would be useful when stepping through case statements, event structures, debugging code on larger diagrams, etc. Also, a split screen feature would be nice. Being able to look at 2 parts of a block diagram, different case statements, etc, sometimes is useful. Support for 2 monitors screens for that feature would be nice also.
i propose to add a "Key Focus" event for each control. We already have Mouse events (leaving, entering) - but when the user (or the programmer) prefers the keyboard (with proper tabbing setup) you have to poll each interesting control for it's "Key Focus" property to initiate a user event...
Add a "Got Focus" (and additionally a "Lost Focus") event to the event structure!
One upon a time there was LabVIEW 5.x and MS Excel...
At that time MS Excel (97 or 2000) could be controlled through ActiveX and some examples in LabVIEW 5.x where showing how to do that.
Each NI partner or LabVIEW user who wanted to control Excel by LabVIEW had to imagine how to save the necessary ActiveX references like Excel_Application or Excel_Worksheet.
Then LabVIEW Report Generation Toolkit 1.0 for MS Office was born. Let's call him RGT
It was wonderful !
LabVIEW 6.x and RGT gave us a lot of functions and a new framework (template) for building our own functions.
The GOOP approach in RGT was including the access of many ActiveX references and parameters through one single reference : the magical "Report Refnum".
Instead of maintaining our old functions, we used RGT and transfered our custom functions to this new environment.
Example of Excel Save As function :
As you can see, it was very easy to get the ActiveX reference and modify them (unbundle / bundle).
Until LabVIEW 8.5.1 and RGT 1.1.2, the weather was nice is this area...
Then came the Objet programming in LabVIEW 8.0 and NI decided to rewrite RGT with this technology in RGT 1.1.3.
RGT 1.1.3 which came with LabVIEW 8.6 was catastrophic in terms of compatibility.
You get a big headhache when trying to build an executable which used RGT.
Some of our custom functions where broken. There was no way to repair them.
RGT 1.1.4 soon replaced RGT 1.1.3 and gave the possibility to get the ActiveX references from the Excel class by adding the "Get ActiveX Reference" to the class.
Most of our custom functions could be repaired but not all of them since the "Set ActiveX Reference" function was not added.
Until now, some of our projets are locked in RGT 1.1.2 and cannot upgrade to LabVIEW 8.6. (or above) because of this missing function.
Mr Eagle Man,
Please add the "Set ActiveX Reference" in LabVIEW RGT 2011.
Radio buttons, rings & enums are used for the same basic purpose: to allow a user to choose from a list of named options, giveng the programmer an integer result. When trying out different UI designs I am unlikely to want to swap a radio control for a toggle switch or "OK" button. I am far more likely to want to swap it for a ring or enum control.
Currently, if I replace a menu ring with a text ring or an enum, I'll get a new control with the same number of items and the same item names. Often no DB editing is needed.
But if I replace one of those with a radio button control, I get a control with two booleans in it, and I have to recreate everything from scratch.
I'd like to be able to replace a ring or enum control with a radio button control and get a radio button control with as many booleans as I had items in the ring or enum, labeled with the item names. (I'd also like to be able to make that transformation back the other way.)