For FPGA programming, sometimes I want a smaller representation of the loop iteration terminal on the for loop mostly just to squeeze every last gate out of the chip. Other times I want the integer to be unsigned or larger to prevent saturation.
In the Build Specifications under Version Information one has the option of setting the Version Number of the build. Ther Version Number is of the form Major.Minor.Fix.Build.
There is an option to Auto Increment the Version Number. If this is selected the Build component of the Version Number is automatically incremented every time the specification is built.
I always use this setting since I can thereby tell the difference between builds. The major annoyance here is that although only the Build component is automatically updated all four controls are disabled and grayed when Auto Increment is selected. That means that every time I want to change the Major, Minor, or Fix part of the Version Number I have to uncheck Auto Increment, make my changes, and then re-check Auto Increment. More than once I have forgotton to re-check Auto Increment, which then screws up my numbering scheme.
Idea: When Auto Increment is selected for the Version Number, only disable and gray out the Build control. Leave the Major, Minor, and Fix controls enabled.
I wouldn't call it common knowledge, but it's certainly not unknown that there are LabVIEW callback VIs that are invoked if present when certain development environment events happen. With the growing prominance of scripting and the increasing ability to develop custom tools to inhance development, I suggest a more flexible approach to these callbacks. Right now, if you want to use these VIs you have to be careful that you don't overwrite the existing VI (if there is one), or you have to manually go into the VI and drop your subVI that you want to run, within the specific callback VI. It would be nice if there was some tool within LabVIEW that allowed you to select the VIs you would like to run on certain LV Development Environment events, and then the paths to those VIs would be fed into the callback function VI to be called dynamically. While us developers could create something like this on our own, a standardized template for a more flexible callback would be nice. This would ensure the developer could create VIs to, say, run on LabVIEW startup but never have to muck with the actual lv_init.vi VI, worry about what's already in the VI and overwriting it, etc. They would just have to configure another path to a VI for the lv_init VI to call. If anyone has a more flexible idea, please feel free to add to this.
A queue message is basically the same thing as an event; a notifier notification is very similar.
I suggest allowing us to handle queues and notifiers with the same Event structure as User Events and Front Panel Events.
I find it a problem that free labels by default have the same color as native functions; there is no visual distinction in meaning. Hence I always have to change my free label colors... and I expect a lot of people use color on their free labels to mean different things.
*** SUGGESTION/IDEA ***
I suggest allowing the user to set the default FG/BG color of free labels in the LabVIEW Options.
Perhaps a different setting for Front Panels and Block Diagrams would be appropriate; that also would eliminate the "use transparent free labels" option from the Block Diagram options.
*** Other Train of Thought: not a full idea yet ***
As an interesting follow-up to consider I also suggest considering the use cases for free labels. Perhaps there should be a way for the user to create different types of free labels and assign them default colors; if that were the case it would be cool to be able to seach for "High-Priority Labels" in all opan VIs....
Here's a problem a lot of people have encountered.
You want to implement a nice UI and decide to do some fancy UI programming with mouse actions being linked to certaina ctions on the FP. Nice and fancy until the mouse cursor leaves the bounds of the front panel. If I have a mouse action on the FP requiring me to hold the mouse button down and I then move out of the FP and release the button, LV does NOT realise that the mouse button has been released and the code int he FP still reacts to the currently un-pressed mouse button.
This is annoying and has been around for longer than I can remember. I recall hearing that the proper implementation is not trivial, but there must be some way around this. Please?
Give the user the ability to save the LabVIEW source files as un-completed, version independent files capable of being imported to any version of LabVIEW. Of course, newer features won't be recognized, but the vast majority of the code should be useable.
I'm growing increasingly tired og all the clicking in the BD to configure all our nodes and structures, and am searching for better ways the IDE could help us get (or get rid of) the items or settings we want. One category of configuration is our structures, for instance the For-, While-, and Timed loops. So this idea covers a couple of changes to those structures:
1) I suggest it should be possible to hide the iterator terminal in loop structures. There's no law that says it must remain present, in case we don't need it.
2) I suggest two easy ways to hide optional terminals (the iterator terminal in general and the conditional terminal in For-loops), namely selecting a terminal and pressing DELETE should hide the terminal, and dragging a terminal outside the structure and letting go of it should also hide it;
3) Making a terminal visible again should also be simpler than right-clicking and enabling the correct option in the context menu (that option should still exist of course, as it remains a standard way to find stuff if you don't know a better way). I suggest one or more "selection areas" be defined along the border of the structure, which upon mouse entry would popup a terminal you could drag back and drop into the structure. In a For-loop such a "selection area" could be the lower right corner, of course not overlapping the resize handle:
When you move your mouse into such an area a selection menu should appear, from which you can drag stuff or enable a setting or whatever:
The "selection area" should be relatively small so you don't activate it all the time by accident, but large enough that it's easy to hit. You should also be able to dismiss the popup with ESC or CTRL in case you wanted to do something else in that area of the structure.
Isn't this easier than clicking and navigating into nested menus all the time? Even the "Visible" context menu could be such a hover and enable/disable bubble...
I'd love it if the LabVIEW developers optimized the search speed for searching pallettes for VIs. When I hit the Search button on the Controls pallette, it can take 30 seconds or more before I can search as it says "Populating List...Please Wait." It would be great if LabVIEW could populate the list as a background task sometime after startup such that when we need this function it would be ready to go without waiting.
There are some dialog boxes in LabVIEW that I think need to have a "set as defaults" option available. As an example, there are a lot of form fields when building installers for my applications that need to always be the same (or almost always). In particular the "Version Information" section:
This is something that is rather minor. However, as a day-to-day LabVIEW developers, filling these fields out over-and-over again has gotten old. Thanks for your consideration.
Currently, a class is created with a Class Private Data Cluster. Each data member of that cluster is scoped exclusively to the owning class. For access to these data members outside class member VIs, getters and setters (accessors) must be established individually for each element. These accessors can then be scoped accordingly, allowing access to the private class data through the accessor VI, or in 2010, through an accessor Property Node.
Quite frankly, I like the IDE interface for accessing class data members using Unbundle/Bundle by Name. This feels natural for LVOOPers who have a background with clustered typedefs (which means everybody). Unfortunately, this method of data access is reserved for callers within the scope of the class data. Currently, since all class data is private, you can only use Unbundle/Bundle within Class Member VIs themselves.
I would suggest an options interface for setting the scopes of Class Data Members. Having non-private data member scopes has benefits:
LabVIEW has a success story due to it's ability to program graphically. But the new LVOOP features still lacks the graphical touch. On the other hand, the text based SW is catching up with graphical modelling concepts as uml.
So instead of a simple config editor to set the inheritance, I request to have this completly graphical.
It's THE main feature of LabVIEW to do things graphically, so why fall behind this standard? No, not this tree control, but draw a wire to the parent, uml is already showing the way.
Create a shortcut or a series of shortcuts to all a "Select All" on specific types of elements on the block diagram. For example, "Select All Controls", "Select all Containing Structures" or "Select all wires within area". You can do and select and drag now but often this selects other items within the selection area. This is simply a shortcut for selecting multiple items and allow some level of filtering on the selection.
there is an idea about making labview.ini and other user configs to the corresponding user folder .
I propose to go a step further and make the LabVIEW environment project based, which means that you can define a labview.ini file, VI templates (including standard VI, if you create a new VI), palettes, QuickDrop stuff, etc. inside a project.
E.g. templates are saved in a custom location and linked inside the project. If you do this and start the "New..." dialog, than all your templates inside the project are listed first (below project).
If you do not use this feature in your project, the default files are used (default meaning the way LabVIEW works now).
This way it's a pain to "copy past" image from one to the other control. It should be possible to customize two controls at a time
Have you ever found yourself wondering what was going on with a sub-VI on a deployment system, but could not view what was going on with the VI without going to your development system? How about an installation that allows someone to view a VI front panel and block diagram that is not locked or password protected?
The Report Generation Toolkit does not allow you to delete a worksheet (or anything as far as I can tell). I realize that it is a "generation" toolkit, but it does have modification functions such as being able to overwrite a cell. Deletion is a modification function of sorts and it seems like it is a pretty basic function. Also, figuring out how to open an existing file is not obvious. You have to use the New Report function. It turns out that you can use an existing file as the "template", but that doesn't show up in the documentation. Rename the function as New/Open, something similiar to the file I/O Open/Create functions and at least add a note to the help file.