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....
I can run exe's built using an application build, but not the "setup.exe" from an installer build (the "Run From Build" button is disabled and grayed out):
As far as I understand undo management in XControl, "DisplayState" is memorized each time "State Changed" is set to true in "Action" Cluster. Undo step is limited by the configuration of "Maximum undo steps per VI" in LabVIEW environment.
It would be interesting to have more control on this mechanism:
- be able to clear the undo memory
- be able to skip a memorization when "State Changed" is set to true. (idea : memorized the state only if "Action name" is not empty.
- be able to set the maximum undo step independently from LabVIEW configuration (idea : use the init ability to define this)
Last item wold be useful to avoid too large memory consumption when "Display state" contain lot of data.
It's sometimes bothersome to have to go create an event then go get your control and drag it in to that new event case. I would like to be able to drag and drop a control into the event structure in any case and have the option to either place it in the case you have currently selected, or pop up the dialog to create a new event case, then have it dropped in that new case automagically.
At this moment when I create constant on Which Event Input (Get Last Event Method):
it looks like that:
and every time I should go to help to check which number is responsible for Click, which for Draw, etc... (Usually I using Ring constant obtained from IMAQ WindLastEvent).
Compare it with IMAQ WindLastEvent function:
Do the same in Get Last Event Method. Please replace meaningless array of I32 with array of Ring Constants:
I don't like and don't use the Auto Grow option of structures. Therefore, I always uncheck Place structures with Auto Grow enabled in the LabVIEW options. A visual mark on the structures or a specific entry in the Find and Replace dialog box would help me to locate these structures on inherited VIs.
Please add labels to the "picture items" selection in the control editor for customizing button controls. This would help the developer know which button state is selected for a picture import. Labes could be as simple as "T, F, T->F, F->T ...."
I have several Labview versions, and some files are in 2010, others in 2011.
I often work with both version launched, and when I want to open a file, I have to do File=>Open and choose the file (with the good Labview version). Opening a 2010 file with both version 2010 and 2011 launched open my file with 2011, whereas it has been saved in 2010... (maybe a bug ?)
I would appreciate if I could drag and drop the file I want to open on the LV icon on taskbar (+1000 to the following idea : here)
Within the Project Viewer it is possible to create virtual folders in which to help you organise your VIs. Why is this feature not available in the "Build Specifications" area below it.
The main project I am using has 15 different items here, most are grouped (I have a .exe and a .installer for each variant of the software I am creating). It would be nice to group these in folders as my project is getting messy.
Charts and graphs in LabView have been driving me nuts for years. What I would like to see is a simple chart (maybe even an "Express Chart") that has a single dimensional array input and a timestamp input. Values in the array would automatically be plotted on their own plot and the time stamp would be put in the X-axis starting from the left. An option to just use the current time if no timestamp was input and amount of data displayed on the X-axis can be adjusted on the fly by setting the X-axis TIME/DIV
Panning around the VI using the scrollbar is way too slow. Using the scroll wheel only goes vertical. The Pan tool is nice but I never switch over to it when I should. LabVIEW should support the swipe gesture on the Front Panel and Block Diagram. Swiping is a gesture done by clicking and "throwing" the canvas one way or another (kinda like minority report). The canvas keeps the virtual momentum of the swipe and continue to pan the screen until the user clicks or the screen slows to a stop. This interface is one of the main tennants in iphone navigation for panning through tables, around web pages, and really anything that is larger than the view.
Since LabVIEW coding must be a left to right allignment to look clean/understanding and maintian the dataflow, It would be better if we have the default scroll to be activated from left to right (horizontal).
In current versions, we have to roll over the mouse to horizontal scrollbar to scroll left/right. but by default, scrolling anywhere scrolls it vertically.
Perhaps we can have an option to enable the scroll to vertical or horizontal?
When developing a utility to traverse any control using VI Server and save its contents to a file (similar to the OpenG utility using Variant) it is quite challenging to find out the size of the array's data.
There are various workarounds, but all of these are relatively tedious and over-complicated.
Why don't we have a "array data size" read only value on the property node of an array?
This would make things MUCH easier.
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 have run into the problem from time to time that I create a new build specification in my project, hit the Build button in the setup dialog just to have the build hang or crash LabVIEW. To add insult to injury when I opened the project file again (sometimes even after recovery) that new build specification was not there since the project was not saved before building.
I have now trained myself to resist the temptation of hitting that Build button. Instead I will exit the dialog, save the project and then start the build via a right click.
I would really like to see the project file being saved before the build is executed.
Many of my subIVs involve complicated computations and can take a long time to return. They are called with a "subVI Node setup" of "Show front panel when called&Close afterwards". The front panel often consists of a progress bar and maybe an interrupt button.
As computers become faster, or when the current math problem is small, the subVI just flashes for a few hundred milliseconds, too fast to really see much or interact. This is distracting and useless.
I propose a delay setting that would open the front panel only after e.g. one second (configurable) of subVI processing has elapsed AND the subVI is still not finished.
This will have the following effects:
Of course this could all be implemented in code, but I think a native option would be more useful. Here's how the new subVI node setup could look like.