I currently have a project with an auto-populating folder for documentation. That documentation is included in my Installer build specification.
If I regenerate that documentation while the project is open, the auto-populating folder sees it disappear from disk and removes it from my installer! No notification, nothing. Just completely silent. This has resulted in shipped installers with missing documentation
I propose this should work the same way any other dependency does if it disappears from disk. It should break the installer from building and show a warning sign that the dependency is missing.
Today, if we want a FOR loop with a fixed number of iterations, we need to wire a diagram constant to N. We could probably save a few clicks if we could click on N and type in an integer directly. It would also unclutter the diagram. This should of course only work if N is unwired.
Of course the N-Box would grow to the right to accomodate all digits
To later change the loop back to "normal", we would type N into the box or simply wire something numeric to N from the left.
As an example how it could look like, here's a simple cross product implementation (Yes, I know, LabVIEW already has a cross-product, so this is just to show the idea!)
Top: current implementation
Bottom: Same code after this proposed idea has been implemented
It's a little annoying to try to draw long wires to a terminal that's currently off screen -- you have to hold your mouse at the edge of the screen and LabVIEW slowly scrolls the window (Shift will speed this up a little bit). Currently, neither the mouse wheel nor the touch pad work for panning/scrolling while a wire is currently in progress.
As an improvement, it would be great if the mouse wheel allowed panning the diagram while the new wire was still in progress.
It is not obvious that a NaN numeric constant can be created by simply typing "NaN" as value. What we see are weird constructs, e.g. "zero divided by zero" or "square root of -1" to generate a NaN on the diagram.
I suggest to add a NaN diagram constant to the numeric palette to make it more obvious.
(This is just a quick draft. Of course it should be matched in color and design to the other constants)
At least not at first. The compiler could inline each prototype and when called repetitively, use normal recursion. But that would be next level, and maybe not even desirable.
The scalar string input is simply not a stable input for this malleable VI. It will always result in infinite recursive compiled code. So, this should break the caller.
Of course, it should be perfectly legal to have a disabled type specialization case that calls the same prototype. As long as it's not actually compiled, that's perfectly valid:
Right now if you have a string constant in a VI and you edit it and save it, LVCompare just highlights that the string constant has been edited. For small strings, not a big deal. However I have a bunch of big long SQL query strings. In that case LVCompare is pretty useless. I know I changed the string constant, what I want to know is what did I change in the string constant.
The IDE would be more consistent if all the toggle-able features were collected together under the "Visible Items" submenu. Photoshopped example of a FOR loop below, but I'm sure there are others. "Show Dynamic Event Terminals" comes to mind...
Large string constants, like to one shown below, can really get in the way. I would like to double-click the border and have it collapse, like the LV 2010 Cluster now does. Putting large string constants in a VI, or rolling them up, are some work-arounds, but this would be easier...
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)
In LabVIEW project file XML some information are generated by LabVIEW. For example:
Dependencies
PersistantID
FPGA stuff
...
These information should not be commited to source code control system and having them within the LabVIEW project file makes it very painful to maintain a clean GIT history.
It could be very convenient to store these information into a separated file with a specific file extension so that we can easily ignore with .gitignore file.
A portal view to the Front Panel elements from the Block Diagram through a feature like "View As Portal". This would be especially useful in the case of G codes doing calculations, simulations, and modelings in the Block Diagram for people like researchers, scientists, and educators.
Sometimes we have a need to do some mild synchronization between otherwise parallel tasks. Typically we would use a flat sequence (but there are also exceedingly fancy tools such as "Rendezvous"). Even a flat sequence is often overkill for the given situation: It is a 2D object with it's own diagram and input and output tunnels. We need to decide what should be inside and what should be outside.
I suggest to extend the idea to a 1D object: The "Synchronizer Bar". It is basically a flat sequence with zero frames, condensed to a single vertical line (Maybe we could even allow kinks in it???).
The function is very simple and immediately intuitive (as anything in LabVIEW should be!!) and can be described in a single sentence:
"No data can leave any of the tunnels until all tunnels in the structure have received data."
Ideally, we should be able to "free-hand draw" this structure interactively with the mouse and a tunnel will be automatically generated for each wire we cross.
Here is a dumb (but illustrative) example (ignore the code itself). That's how it could look like.
(At the moment I simply merged the edges of a flat sequence, but I am open for prettier suggestions ;))
Overall, it should be closely related to the flat sequence and include certain right-click actions (e.g. Add frame before/after, which would expand it into a flat sequence).
The Project page of the Project Properties window contains the Mark Existing Items... button. When pressed, this button enables the programmer to enable the "Separate Compiled Code" setting for all files in the project. This is very useful.
Suggestion: It would be useful to have similar functionality that could enable or disable Automatic Error Handling for all VIs in the project. This could be achieved by adding a drop-down menu that enables the programmer to select whether they want AEH to be enabled or disabled, alongside a button that enables the programmer to apply the selection for all project items, as seen below.
Notes
It may be best to add the button and drop-down menu in a new dedicated Category page named perhaps "Error Handling".
It would be useful to have the functionality available at a class and library level too. Meaning the ability to easily enable/disable the setting for the VIs inside a lvclass or lvlib, but not for the rest of the project.
The "Separate Compiled Code" and Automatic Error Handling settings are similar in that they are both Boolean settings (True/False value) that apply to each and every VI.
