LabVIEW Idea Exchange

There is a need to have the capabilities to make comment about a type def/strict type def control (in the control editor) that are only visible in the control editor.

For instance you might want to point to the person editing the control that he/she should not rename that particular cluster element or this will brake the code (and you may want to use an arrow pointing to the element along with some text).

Currently, if you do that the comment become part of the control and is visible for every front panel instance. This bring absolutely nothing to be able to see that type of comment on the FP and it should not be seen by the user of the control (because this actually make the type def so large an unwieldy).

Therefore, there should be a need to select a group of decorations and mark them has only visible in the control editor .

Note: Right now the only way to achieve something similar to what I describe, is to put the comment in the control description, but this is no great because:

1. People tend to not expect control to have VI description.
2. This does not allow to use arrow and such to directly point  to a specific part of a control.

PJM

For modern application development we need better methods to detect wheter our application is called to open a file.

Currently the only help NI gives is based on command line parameters. And we need to jump through loops to get it working to react on opening a file when the program allready runs.

This is a major showstopper in creating professional applications.

LabVIEW 8.2 had a hidden event for getting this event, which unfortunatly doesn't work in later versions.

What if you need to run exe as admin mode?

Currently Build Specifications is not enought for doing it.

Here you are what you need to do:

1. Built the executable

2. Install mt.exe (https://www.microsoft.com/en-us/download/confirmation.aspx?id=8279)
3. Opened cmd as adminstrator and ran mt.exe -inputresource:"Application directory\application.exe" -out:application.manifest
4. Opened application.manifest and changed input="asInvoker" to "requireAdministrator".
5. Saved application.manifest
6. ran mt.exe -manifest:application.manifest -outputresource:"Application directory\application.exe";#1

Is it an effective method?

It would be better the following:

1. Create Manifest

2. Easy modification in My Application Properties

Hope it helps to do a more effective LabVIEW!

Álvaro

Important disclaimer: I am sorry, this is not my original idea, because it is (together with many other nice features!) already implemented in the LabVIEW UI builder. Credits go to the relevant NI developers.

This Idea posted here tries to see how much interest there is in such a feature and to show support that we want this also implemented in plain old LabVIEW. Personally, I really like it! 🙂

(It is also somewhat related to this idea (but probably not a true duplicate), especially my comment there already exapands on the idea!)

The Unused Items Tray (see also e.g. Christina's Blog entry) is an area on the diagram that contains terminals or FP objects that have not yet been manually placed or are currently only "used" on the BD "xor" FP, i.e. not on both.

The current problem in LabVIEW is that if you place a new control on a complicated VI, the terminal will end up on some random place, typically piled well camouflaged on top of some other diagram structures and possible a scroll away from where it is actually needed. Similarly, if we create a control or indicator from a terminal on the diagram, the control will typically be outside the carefully placed visible area and there is no way to grab it without first messing up the FP alignment by either scrolling or enlarging the window.

In all these cases, it would be nice if the objects on the "other" window would land in a predictable reserved floating location for quick and easy manual placement where they belong. During development, there are probably a few terminals that are not yet used or connected, and we should be able to place them back into the unused items tray of the diagram so they never scroll out of view or get misplaced.

On the front panel, we might have some spare controls "parked", and they would not show in run mode at all. This could even be abused for "local variable zombies" (=hidden controls with the sole purpose of making a local variable) along these lines, which might be OK (=better than hidden controls!). Front panel items in this tray would look like their palette entries. We don't want e.g. full-sized graphs in there!

Now, how should all this look like? In order not to cover valuable diagram space, it should be something that collapses to near nothing when not used and would only expand to show the current contents when hovering or clicking in a special area. Of course there should also be an option to pin it open. When minimized, it should look different when "not empty" vs. "empty".

When you or two numeric numbers it does a bitwise or.  The same should happen when using Or Array Elements, but it is not supported for numeric arrays. I see no reason why it shouldn't work just the same?

I would like to be able to create BD array constants from the predefined string and numeric constants.

Presently you cannot create an array constant by dropping a predefined constant into an empty array box on the BD.  Arrays of string constants such as Carriage Return, Line Feed, Tab, and Space need to be created programmatically using build array or manually using the '\' codes or hex codes.  Arrays created in such a manner do not have the graphical indications of what is contained.  Some of the constants (Space) are actually VIs, which may complicate things for NI.

Similarly the Math and Science constants like pi and e should be allowed to be dragged to an array of DBL.

Lynn