LabVIEW Idea Exchange

Top Authors

User

Kudos

Post an idea

When distributing a built application, the about box needs to follow certain NI guidelines regarding copyright notices and such. In order to remain compliant, I typically don't create my own custom about box, but simply leave the stock runtime engine "about" screen intact (see also this discussion and this earlier idea.).

This seems to be more complicated that necessary.

Since NI has certain requirements about what needs to be on there, I propose an "About box" editor, accessible from the "build application" dialog. It would start from a template with all the required components present and some standard fields and panels that can be customized. (In some ways, this would be similar to the installer build, which allows embedding of custom images, etc. for the install dialog).

There should be automatically updated "variable" fields, allowing for automatic content generated a build time: For example the "build version", "build date", "toplevel file name", etc.
It should allow the presence (or absence) of optional components currently visible in the stock NI LabVIEW about box, such as memory usage.
It should allow for custom buttons and web links (e.g. to a local readme or a company website, etc.)
All fields should allow custom background coloring, including background images.
etc.

Here's an image of the current LV 2009 about box. There are many areas (e.g. A, B, C, etc.) that would allow full customization. Required components, such as the copyright notices should be static and not removable.

We should be guaranteed that if we create an 'about" box with this tool, it conforms to all NI requirements, including for all toolkits that are part of the build.

colors of plots in a new grphics controls

the color of a plot is normally auto-assigned to 10 differents colors, and this is repeat a 10 th to 19 th plot........ and more, these colors in the modern palette are correctly configured, becouse the background color is black, the colors are good contrasted, but in the new plot controls on the silver palette, the first plot it's blue, but the 10 th plot it's white, and is not possible to see them, in the digital plots the problem is similar but in this case de first plot is white also. see the added figures.

View All (4)

A major caveat about SubVIs documentation is failure to update description when code is modified. Also it is not obvious when opening a VI wether a documentation even exist for this VI (even though it is quite easy to figure out hovering the icon with Help Window on). At last, editing documentation in LabVIEW requires several clicks and menu browsing.

To help better maintaining VI documentation, I always write VI description as a text header on the VI front panel (top part) and replicate it into the official (burried) property field. Although redundancy generaly complicates proper maintenance, in this case it helps in many ways !

I therefore suggest VI documentation be integrated to the front panel as a header, when it exist. User may need to hide it for editing large GUI panels, but documentation header should always appear for SubVIs. It sounds logical to make it editable (to ease documentation maintenance again).

View All (4)

If we have a 1D array wire and try to insert a "rotate array" primitive (right-click...insert...), there is only one reasonable connector choice.

When inserting symmetric primitives, the programmer can typically chose the connector used by placing the cursor slightly above or below the wire when right-clicking. For numeric arrays, LabVIEW is smart enough to always automatically pick the right choice when inserting a "rotate array" primitive. Obviously, there are additional sanity checks, preventing broken wires.

For some reason, this is not true for non-numeric arrays. If we (for example) try the same with a 1D array of strings, we get a 50% chance of broken wires and useless connections. (same for other non-numeric types I tried, but I did no check all possibilities)

A picture shows it better. (As mentioned, we always get case (B) for numeric arrays)

IDEA: The smart behavior should apply for all 1D arrays, not just numerics.

View All (2)

If the output terminal of "Bundle" or "Bundle By Name" is unwired the vi should should show broken arrow.

You can ask me the question why?

Consider a scenario of the below picture. As soon I wire all the input terminals and input cluster of "Bundle By Name" the vi is in run mode. There is nothing wrong in that, But if I forget to wire the output terminal of bundle by name...... You know what will happen. If it happens in a sub vi of a very big project it is very hard to debug, More over there is no use in any scenario to leave the output of the Bundle By Name unwired,

In the above picture the vi is in run mode when unbundle by name output is unwired

In the above picture the vi shows broken arrow when "bundle by name" output is unwired

View All (3)

I suggest that NI should spend a separate Excel-like editor to edit the Tables in LabVIEW.

There are many proposals how to improve the LabVIEW-Table and its editing.

I recommend to stop thinking about improvements and add a separate Excel-like Editor instead.

This Editor could be used to enter, manipulate copy and paste table data. Perhaps more functions like loading data from a file could be added and integrated.

It should be accessible in the editing and running mode.

It should be possible to use it for controls and for constants.

It should be accessible by selecting a corresponding entry in the pull-up context menu (right mouse click).

I hope that this is not another duplicate to this table editing problem

View All (3)

Add UI alignment lines

A well documented program requires descriptive labels, but LabVIEW makes it difficult to show the label of diagram constants.

If we change a control or indicator to a constant, the diagram constant retains the same label, but the label is now hidden. 😞
Same if we right-click a terminal and create a constant. 😞
If we place a diagram constant from the palette, the label is hidden by default. 😞
...

In 99% of my programs, virtually all diagram constants show their labels. They are a vital part of the code, document it clearly, and prevent coding errors.

IDEA: show labels of diagram constants by default

If we convert a control or indicator to a diagram constant, keep the label and show it! 😄
If we create a diagram constant from a terminal, keep the label and show it! 😄
If we place a diagram constant from the palette, switch to label edit so we can start typing the label. (same as when placing a control on the FP!) 😄

Examples Scenarios to prove my point:

Often I read from spreadsheet file and want to transpose, so I right-click the terminal and "create constant". I get a boolean diagram constant with the label hidden. I would prefer if it would show the "transpose?" labels! This way I can ensure that I did not accidentally used the "append" terminal instead of "transpose". Also, if I edit the program later, it is clear from the label where the boolean goes, even if the wire is mostly hidden.
Often, shift registers are initialize with a diagram constant. I use the label of the diagram constant to hint at the content of the shift registers. Labels could be "insert point", "averaged data", "counter", "state", etc. etc. Code is clear and self-documenting. No need for extra diagram comments that might go elsewhere during a diagram cleanup.
I might have a control, that (after debugging) will never change again and I thus convert it into a diagram constant. Also here, it should retain its original label and show it. ("Npts", "Frequency", etc.). Again, this keeps the code readable and clear.

If you click on the calendar button of a date & time control all updates of the user interface and all functions that happen to run in the user interface thread are halted/blocked.

This is, as far as I know, because the calendar is really an ActiveX control...We need a native control that does not show such behaviour (especially considering the fact that things like the run method is running in the user interface thread...).

It is quite ugly that such a fundamental control as the date & time control depends on code that will block the GUI.

View All (4)

There are many properties that have equivalent event terminals. Unfortunately, they are often named or typed slightly differently, creating lots of coercion dots for no real good reason.

(I've run across many more over the years, so this is a very incomplete list. Feel free to post other cases here ;))

For example (property vs. event terminal)

Active cursor (U32) vs. CursIdx (I32) (why U32 vs I32?)

Cursor.position (Cursor X, CursorY) vs. CursLoc(X, Y) (example from here)

(note the coercion dot on the event output tunnel)

Every time I build an installer I have to manually change the following Dialog settings in the SETUP.INI file.

[Dialogs]
UserInfo=0
FeatureInfo1=1
SingleDirectory=1
InstallationType=0
FeatureTree=0
License=1
License2=0
NICertificate=0
ConfirmStart=1
End=1

These settings allow to (a) only show mine or NI's licence agreement. (b) install directly to default directory without prompt etc..

This should not be necessay and these settings should be exposed to the user with the Installer Properties under Dialog Information (see image).

View All (4)

System Boolean Tweaks

I am reaching the point where I use System Controls almost exclusively. The look may be improved, but there seem to be some shortcomings with the System Booleans.

First, if you haven't already, then please read (and Kudo) this Idea:

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Get-rid-of-automatic-key-navigation-assignment/idi-p/1093280

One of AQ's suggestions there is quite good: Add a Generic System Boolean. Our current choices are both automatically tied to Keyboard shortcuts. It would be nice to have one that isn't (assuming they won't strip all default assignments).

Next step: Change the labels of the existing system booleans to match the button type. Both the OK button and the Cancel button are labelled 'Boolean'. Only the new generic button should have this label.

Add a System Stop Button: Consistent with the other buttons, the label should be Stop. This should be created when you Create Control from a Stop Terminal when the default style is System. Right now you get a button with Stop as the Boolean text, but with the label 'Boolean'. If you are a 'View as Icon' type, then there should probably be more than a blank icon here.

Add a System LED indicator: The following post is a fabulous place to start, something like this should be shipping with LV

http://forums.ni.com/t5/LabVIEW/system-style-boolean-indicator/m-p/1172877#M510484

Bonus Idea: Provide a simple way to add a glyph to a boolean button. Even fixed sized, fixed location would be very nice. When visible, the boolean text could be shifted automatically. No need for a proliferation of custom controls when many cases are just simple pictures placed beside the text (check marks, red X's...).

Clean Up Options Preview- LabVIEW

I find the clean up button in LabVIEW really useful.

However it does not always clean up in a way that I want - moving code around, compacting too much in some place etc.

This can be improved by playing around with the clean up options but that way requires a lot of trial and error before it is just right.

What would be great is if LabVIEW gave me a series of mini preview windows of what the cleaned up code could look like. Each window would show a different style. i.e. one window might prioritise making the code compact so that it fits onto one screen, another might prioritise making the code easy to follow and understand etc etc.

Take a look at the attached file and you'll see what I mean.

View All (1)

Full XML support

In Visual Studio you have XML Schema tools etc. It is a breeze to e.g. populate a drop down menu based on XML from a web service, and my first thought when I see it in action is - why do we not have this at our fingertips in LabVIEW already? LabVIEW could have made it simple to create schemas, generate flexible XML etc. You could have wizards that helped you, and cluster to xml conversion like in EasyXML from JKI - and it should all feel fully integrated (toolkits are OK, but this really needs to have native support).

I am currently developing a web service in LabVIEW and the first thing I had to do was to abandon the few in-built XML functions and write my own serialization code (using terminal mode for the web service gave you XML without proper headers, and the in-built flatten to XML outputs XML is impractical in use). Once I have serialized a text table e.g. and published it - using that table feels incredibly easy in Visual Studio (add data source-> input web address etc.) , it would be much more difficult to do the same in LV.

I think NI should make a big leap in the use of web technology. The RESTful web service functionality was a great addition, but the doumentation is non-existing, and we should have come much further by now. I know there are some cool experiments going on with web based GUI editors, but LabVIEW 2010 was just released with very little news on this front so forgive me if I rant a bit...

This may not technically be a standard LabVIEW Idea, but it is an idea nonetheless and there is no where else to post this idea in the Idea Exchange Forum and I want get other peoples feedback.

I would like to suggest that sending packages (.ogp, .vip, .vipc files) to NI Support is an acceptable way to submit code for reasons relating to code (support, issues, review help, CARs).

I have had problems sending code and then sending all dependencies as well, along with instructions on where to install etc... (for example here) that was solved once I was able to convince my support AE to install VIPM. It also saved me a lot of time (other I had to rebuild code in order to send it as well etc...)

(IMHO) I think this Idea would compliment NI moves towards establishing it's LabVIEW Compatibility Program (which I am assuming VIPM and OpenG will be covered under)

Additionally there seems to be great acceptance by NI to packages already whereby I have seen NI code in documents/white-papers posted as packages.

Thanks to Christian L and Laura F these files types are now compatible with the new NI Forums.

Here are some of my notes on this Idea:

VIPM Community Edition would have to be installed internally (but it is free so there would be no cost)
I am not looking for NI to support VIPM itself (unless it is covered under the Product Partner Program?) only that I can send a package to NI Support and they will know what to do with it and be able to install it
OpenG would also be required to be installed as well (after all it is the LabVIEW main/only? Open Source movement) (this is free too).
That way I would not have to send large dependencies files (only include my internal package), and then email size would not normally be an issue (although I have used NIs FTP successfully in the past due to large files) but email is nicer.
All this would lead to a more streamlined approach to Support for those developers who rely on packages

Please post your feedback.

Cheers

-JG

View All (13)

View All (4)

The problem: Free Labels may take too much space on BD to hold all information.

Idea 1: Allow Label to have help. With this simple change, the programmer puts the essential information in the label and the details in the help.

Idea 2: Create an option to current Free Labels or create a new kind of Free Label, that has a behavior which a hidden part of the information is shown, in a drop-down "flap", when the user hover over the Free Label. The label could have two fields, one for the permanent information always shown (current bahaviour), the other for the additional information that will be shown when the user hover over the Free Label.

Free Label with Drop-down additional information.png

View All (8)

LabVIEW Idea Exchange

"About..." box editor for built applications

colors of plots in a new grphics controls

Installer option to include fonts used/required by application.

VI Documentation as an editable header on Front Panel

Smarter insert behavior for non-numeric arrays

Unwired output of "Bundle" and "Bundle By Name" should show broken arrow

Edit LabVIEW Table in a separate Excel-like Editor

Add UI alignment lines

Show labels of diagram constants by default

Calendar control that does not block the GUI

Can we get consistent naming and datatypes for equivalent properties vs. event terminals?

Dialog settings in Setup.ini to be selectable within Installer Dialog Information

System Boolean Tweaks

Clean Up Options Preview- LabVIEW

Full XML support

Sending Packages (.ogp, .vip, .vipc files) to NI Support is an acceptable way to submit code

Make App.Version return the application version, not the Run-Time version

Saving Space when Using Free Labels for BD Comments

Default Browse button on File Path control

Drag & Drop a VI from llb manager to a diagram