LabVIEW Idea Exchange

It seems there are a lot of NI services that start running directly after logging in to windows.  I even tried manually turning them off using msconfig thinking the services would start when LabView was loaded or on an 'as needed' basis, but I was wrong. 

The user should have the option of starting services at windows startup or at LabView startup, or even not at all if it is not required.  Perhaps this could be added to select the services within LabView's 'Options' menu.  An explanation of each service and why it is needed would be great also.  With all of the programs that run on our computers these days, the less running in the background, the better.

When selecting objects on the Front Panel and using the Shift + Up or Down arrow key, it moves them to the nearest grid line and successive shift+arrow keys keep things on the grid.  This is fine when selecting a single object, However, when selecting multiple objects that are not perfectly aligned, it may result in a misalignment.

The idea being suggested is when multiple objects are selected they should retain the original alignment between objects.  A more sophisticated version could allow the user to select in the options whether objects that are aligned within a given small number of pixels should automatically be perfectly aligned and moved together.  The idea is to prevent having to re-align an object after using the Shift + Arrow to move them.

See image below:

Problem:

Lets say you're writing a VI for stopping a process. Wanting the icon function to be recognizable at a glance, you open the icon editor and go to glyphs looking for this:

You type "stop"... nothing... hmm. After muttering a few curses, you either trudge through the whole icon library, or you draw one.

Turns out you should have written "abort"! Oops. Not really intuitive.

Solution:

Turns out the glyph search is fairly useful. It can see if your search is in any part of the glyph file name. If the above glyph was named "abort stop.png", the search would have succeeded.

Glyphs would be a lot easier to find if they contain the noun and a handful of verbs that they represent. For example:

"support.png"   -> "support checkmark yes.png" (support?)

"keep.png"     -> "keep checkmark yes.png" (keep?)

"create.png"     -> "create new.png"

"file.png"         -> "file disk save.png"

Alternate Solution:

Impliment tags into the glyph library with the ability to add new tags to current glyphs. This would avoid long file names.

The Message Box from LabVIEW doesn't look very nice. On Windows Systems user32.dll provide a better Message Box.

See also MSDN entry at: http://msdn.microsoft.com/en-us/library/windows/desktop/ms645505%28v=vs.85%29.aspx

It is possible to set the Buttons

• Abort, Retry, Ignore
• Cancel, Try Again, Continue
• Help Button (!!!)
• Ok
• Ok, Cancel
• Retry, Cancel
• Yes, No
• Yes, No, Cancel

Icons for

• Error, Stop
• Question
• Exclamation or Warning
• Asterisk, Information

and many more ....

LabVIEW should support this MessageBox on Windows Systems as additional MessageBox beside the existing.

When String is connected to path, then wire is broken as expected, but we can insert String To Path conversion primitive with single mouse click:

Please do the same for the case when Boolean connected to Numeric:

Thank you!

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

We've had a few recent discussions relating to labels of block diagram objects. I don't think the following came up yet, but I think it's one area where improvements are really needed.

If we create a property node or invoke node, it has a label indentical to the linked object. However, this label can be changed to anything we want, possibly leading to code that is very confusing! For example if we had two terminals labeled A and B, we could label the property node linked to A with "B" and vice versa, completely obfuscating the code!

(The beginner could also incorrectly assume that changing the label is the correct way to change the association to a different terminal)

These nodes should really have the label of the linked terminal hardwired to the corresponding terminal name, because anything else simply would not make a lot of sense.

My graphic is not as nice as Jack's here, but I think the idea is clear. It would certainly need a few tweaks from the art department. 😉

We might need an option to hide the label. Oversized labels should be truncated for display, only showing the full text when hovering.

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