LabVIEW Idea Exchange

I wish to have the option to pin the (relative datatype) pallette opened thro' short-cut menu, like inthe attached snapshot.

The use-case I feel is, most of the times when I want/need to navigate to the related datatype pallette in search of something, suddenly I find that I need more than one function to be used in my next steps of coding. So during those times, pinning is a viable & useful option.

Hope some of the folks would agree with me...

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.

One of the annoyance of designing a UI is that you will never know for sure how it will look on another user computer.

For instance, you design your UI with the default 13 point font size and when a user that has it default font size set to say 16 (and with a different font type) open your UI everything is a mess (text run out of the screen, text overlay controls ...).

In built application (meaning in an exe) one can add the following line to the executable and this fix the problem by coercing the font type and size.

• AppFont=""Tahoma" 13"
• DialogFont="Tahoma" 13
• SystemFont="Tahoma" 13
• CurrentFont="Tahoma" 13

But what about a reusable tool that are basically a source code distribution?

Currently, the simplest way to ensure this outcome is to write a reusable VI that will recursively set the font size and type of every labels or string to be what you designed your UI to use. This VI has to be run by the UI every time it starts.

What I propose is to add a global VI settings (probably somewhere in the VI properties) that will persist whatever font settings was used to design the UI.

This setting should default to false.

The image above is one possible solution (the simplest one).

Another solution would be to explicitely defined what every font style&size should be for every font type (something very similar to the explicit definition one can use in an ini that I mentioned above). In that case, there could be an entirely new font category in the VI properties.

PJM

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

I am taking advantage of the recent FileVersionInfo to pull up the Version Number of the Executable at Run Time and display it for the User (who can then call me and say "Version 2.1.3.4634 crashed", and I can figure out which source this was).  I take advantage of the Pre-Build Action to create the Version Number, taking the "Build" part from the Revision Number of the Project itself (since the Pre-Build Action gives me the path to the Project, this is fairly straight-forward).

However, in order to get the correct Build to appear in my Executable, I must build twice.  The reason for this is that LabVIEW apparently reads the Version information before executing the Pre-Build Action, so my attempt to set it to the "correct" value is ignored until the subsequent Build.

Personally, I think it is illogical to have a "build Action" that silently takes place before the user-specified "Pre-Build Action", though there may well be a hidden "good reason" for this.  I would like to request, therefore, that LabVIEW include a "Feature" that specifically allows the Pre-Build Action to include not only setting the Version Information (which it currently does) but allowing this updated Version Information to be used in the current Build.  True, the work-around of "Build Twice, Use Once" works for me, but why should we need to jump through this particular (unpublished and unexpected) hoop?

Bob Schor

Usually I have code inside a loop (e.g. a while loop) that later I need to put outside (or viceversa).  I need to drag the code outside the loop and re-wire the cables. 

It would be great if some shortcut, for example ALT-drag, allows me to drag the code maintaining the cables wired.

And If there were not cables before, creating automatically the tunnels.

Hi,

I think there is too much clicking around in the BD to enable/disable/configure node options. I'd like some sort of context sensitive menu that just automatically appears when you hover your pointer on top of any object in the block diagram. For instance when you right-click the Read from Text File primitive you get this context menu:

You can do a lot of things here it seems, but there are actually only 4 direct configuration points, namely the ones I've highlighted with a red dot. It'd save a lot of right-clicking and subsequent menu browsing if a configuration menu just appear when you hover over an object for a short amount of time (50 ms maybe, the exact delay must be figured out by the UI guys):

  Hover for a fraction of a second...

  ...go ahead and configure the node.

a) The node configuration menu may not cover any of the object itself, thus you'll still have access to the entire object graphic if your purpose was interaction with that.

b) No menu should appear unless your tool is empty. No need to make the node configuration menu appear if you approach the object with a wire for a terminal for instance.

c) Advantages are (at least) no mouse-clicking necessary, no menu fly-out hunting, no grayed options that takes space, no duplicate/triplicate options that takes space, no configuration dialogs that doesn't add anything extra (how about all those Properties dialogs that just lets you edit the object's label in a fancy way, but you have to look, because a new property might've been added in this LabVIEW version?). Just an intelligently populated menu with only the configuration options that makes sense in this context.

d) Help text for each configuration item should be shown in the context help window when you move over each item in the list, possibly minimizing the need for opening detailed help.

e) The short delay from still pointer to menu emergence means you can still move your pointer around the BD without menus flying about everywhere, while the delay is small enough that the menu seems to appear almost instantly when you do hold the pointer still on top of an object.

I envision such a node configuration menu to appear for any node basically. One of the key aspects being that the menu is object and context dependent. For instance a subVI:

... or a tunnel on a While loop:

For some objects there might even be some key information available in this node configuration menu, information that is otherwise several clicks away. For subVIs such information could be if it is inlined, reentrant, has debugging enabled etc.:

Cheers,

Steen

Whenever I drag an object's label or caption I can't help expecting the text justification to change too. Is there any use case where this would not be desired?

The current behaviour is particularly inconvenient when I first drag a label, and then later edit the label text:

I feel that "auto-justification on drag" should apply to controls/indicators/constants on the front panel and block diagram.

A search of the idea exchange turned up a mention of this concept here (credit to M*H*), but it seems to have been lost as a sub-idea of a not-so-popular parent idea. I think it deserves a chance of its own!

One of those little things that winds up bugging me over and over again.  In almost every type of control/indicator I am accustommed to some type of visual clue that a given object is a giver or receiver of data.  Usually it is some combination of shading, increment/decrement buttons, something.  For Refnums (and DVRs in icon view), there is nothing as you can see from the top two pairs of images.

Open question:  Should the terminal in the DVR icon glyph change direction to reflect control/indicator of the DVR itself?  I can think about it and say no, but my initial response is always yes.

In the lower two pairs of images I at least change the color to reflect the system control/indicator background defaults.  Not bad, but it loses some of the shading effects.  Also a bit light against the system default background so a frame may be desirable.

My suggestions:

1) Do something (even if it is not exactly what I want).

2) Change the default shading, tweak frames as needed.

3) Fold the opposite corner for indicator.

(Ignore the fact that I was lazy and reflected the entire refnum icon, I suggest only the corner is switched)

Open question #2:  while I am at it, why does a VI reference control have an icon which also contains a reference glyph?  Seems like a strange Droste effect going on.

Problem - Bundle by name causes unnecessary wire bends because the type specifier is on the top.

Make the type specifier terminal on the upper left and the output on the upper right. Also right clicking on an item will allow you to select "Change to Read" or "Change to Write".

Would look something like the following.

For those of you who haven't signed up yet, you should go and have a look at the Next Generation LabVIEW Features Technology Preview (a mouthful, but in short, it is a UI and Development Environment demonstration version of what NI is cooking up for future versions of LabVIEW). There are some cool things and some downright awful ones.

One of them has been sneaking its ugly neck in LabVIEW 2016: reduced contrast. I am (my eyes) getting tired of it. A few examples of the changes introduced in 2016 are shown below:

2015:

2016:

Considering that the trend is for displays to not increase that much in size but increase in resolution, we have now to factors to fight against: the reduction in size AND the reduction in contrast. I won't mention laptop displays going in economy mode and reducing their luminosity, but the point is that it is making LabVIEW even more difficult and unengaging to use. Way to go to loose any chance to attract new users, and run the risk to loose old timers due to added eye strain.

Put simply: Restore high contrast icons  and please, do not go ahead with the washed out IDE and UI objects showcased in Tech Preview.

I've already made a post on extending File I/O operations so I figured why not make a post on my most commonly used OpenG palette, the array palette.

There are so many good nuggets of Array manipulation code in OpenG.  This stuff isn't perfect, and could be optimized, but the convenience of it makes sense especially when you realize there is so many things you can do with arrays.  Lets start with the Index Array, one of the most commonly used functions.

Here we see the native function allows for an N dimensional array to be indexed.  The OpenG function only supports 1D and 2D arrays.  And when using a 2D array, the OpenG function must specify both a row and a column, you can't index an entire column or row.  Both of those are very useful features of the native index, but there is something the OpenG function does, that the native doesn't, and that is index multiple indices.  You can pass in an array of indices and pull them all out in the order defined.  This can be used as a reorder function that takes an array and scrambles it the way you like.  Adding this feature is already on the idea exchange.

Again when it comes to polymorphism the native function beats OpenG.  The native delete supports deleting from N dimensions where OpenG is just 1D or 2D.  But OpenG allows for deleting multiple indices from an array, and if it is a 2D array you can specify if you want to delete rows or columns.  This would be a nice addition to the native function.

A conditional auto index function doesn't exist natively in LabVIEW.  You can perform a similar function with the conditional auto index tunnel on a for loop but having a single function would be useful.  This idea is on the exchange in multiple places, Link 1, Link 2.

Ever need to remove duplicates from an array?  Or remove all zeros or NaNs from an array?  These two functions do just that and on the forums all the time are requests for functions like this with no direct replacement on the native palette.  A nice feature of the remove and filter are they output the indices that were removed.  Combined with the fact that the delete, and index accept multiple indices make these very useful.  Also the items to filter for the filter can be a scalar or array which is nice.

Ever want to sort an array and know how it was sorted?  This OpenG function can do that along with specifying what order, ascending or descending to use.  The OpenG sort also supports 2D arrays where you can specify if you want to sort on rows, or on columns.

Simple idea: Extend the View as Icon mode for clusters constants on the block diagram to cluster controls on the front panel! Simply right click any cluster and select View as Icon to change it from this to this:

We all use clusters on our front panels of our subVIs, but as we add and subtract elements from them, they shift around and start to overlap other controls or they slip off screen. Many times the typedef cluster is used in dozens of VIs. I don't have time to go fix up the front panels of all those VIs everytime I add a new element to the typedef!

Most of the time the cluster is used in a subVI, and I don't care about being able to see the elements inside it. I would prefer in this case just to see the icon on my front panel. In fact, this is one thing I LOVE about using LabVIEW classes! So why not extend that clean view of subVI front panel controls to clusters as well!

When building an installer, the resulting installer window can be customized with:

• Welcome Title
• Welcome Message
• Readme & License agreements, etc.
• Welcome Graphics (578x383 BMP)
• Banner Graphic (578x59 BMP)

Like in the good old days of vt100 terminals, we are flying completely blind after selecting (hopefully!) correctly sized BMP files and entering all other information, because we have no idea how things will actually look like in the end. There is not even a verification that the BMP sizes are actually correct.

IDEA: I propose a instant graphical preview that actually shows how the dialog will look like based on the entered titles and images. This way we can easily make correction, pick different images, make the title or message longer or shorter, and so on.

The idea could be expanded to include a full graphical install dialog editor (similar to the icon editor) where we can paste (from clipboard, or explorer, for example) and arrange any kind and size of images interactively, scale them, change the saturation (gradient), etc. At the end, the Installer builder would create the final BMPs in the correct size to be used.)