LabVIEW Idea Exchange

At my work we often have structures inside structures several to many layers deep. We try to keep the inner most ones small to keep things to a single screen size overall if possible. But this causes a problem when you have to move an item inside a structure that it currently doesn't fit in. you first have to make room somehow for the structure to get bigger then you can drag the item inside and again shrink the surroundings (the last step can get really ugly when you have multiple layered structures or a lot going on around the outside).

So what if instead of moving the item into the structure you could move the structure around the item. If you could CTL+drag an edge, and instead of trying to push everything around the structure out of the way as it grows, it instead envelops the items you drag over (or spitting them out if you decrease the size). Same basic behaviors as dragging an item into or out of a structure but from the reference frame of the structure instead of the item (or the other way around, not sure how to describe it, kind of like plotting the motion the earth from the suns perspective or the motion of the sun from the earths perspective, they are both fundamentally wrong but both very useful for different tasks).  

     goes to   or vice versa where the only thing that was moved would have been the right side of the inner case structure while holding CTL (or shift or alt or some other equally suitable special key) 

I am guessing that it is not a simple request but would be very helpful to me on at least a daily basis.

Please include mSec value in probe watch. This helps to find the execution time between two events within a few mSec delay. Thanks

Allow tables, list boxes, etc to be able to lock the right hand column. Currently if you resize a table or list box (or any control/indicator with columns) you end up seeing more columns. It would be nice to be able to lock the right coumn so no additional columns are displayed. Most instances of tables have a defined set of columns which will be used and it looks rather ugly to resize and end up with empty columns. The current alternative is to have code running that will do this programmatically which is a bit cumbersome. Effectively this is allowing the programmer to set a maximum number of columns.

One thing prevent our company to upgrade to newer labview is that the run-time engine gets too big. Even I really like the features in later version, I still have to save the files back to 7.1 then to 7.0 to build application installer. Under 7.0, the run-time engine is very small, and the installer is less than 10MB and I can easily email the program to customers. In version 8.0, the run-time engine is 65MB and now the latest version is well above 100MB.

What I would like to see is that application builder get smart, only pick what is needed and build slim app.

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

When a cluster contains refs to different type of controls that have a common ancester, the "cluster top array" primitive should be able to handle it instead of having a broken wire.

Indeed, if the lower snippet works, one can assume that it shouldn't be too hard to get the upper one to work as well when possible.

I'd like to see the Destination Path in the application builder have an option to be a symbolic path based on the project directory (the direcotry where the project file lives) rather than an absolute path. For instance, if the project path (in our case, a local Git repo) was "SS10 Src Repo" and there was a subdirectory called "Builds", it would be nice to NOT have to specify "C:\users\xxx\Desktop\SS10 Src Repo\Builds" as the destination path, but rather check a box to say "symbolic path relative to Project Dir" and simply specify "Builds". If the repo is moved or renamed, all those destination paths in each project file need to be edited.

One reason for doing this is to locate executable that are built from the project, and called from project files via System Exec.vi. At runtime you need to find the executables (assuming they are localized and not in the PATH) and  you can use the Application Directory file constant to figure out where your executables SHOULD be (relative to  AppDir). But configuration to specify their location in each project file using an absolute path is a b**ch...  it would be great to not have to edit all the dest paths in each .lvproj each time we check out the repo on a new machine, or by a different user...

Populating the Tree Control with items takes very long time.  I suggest improving the performance of a tree control.  Many other applications have tree controls that are populated in a small amount of time, so it should be possible with LabVIEW.

I know of three ways to populate a tree control.  The first is to individually add items using the Add Item invoke method.  This method takes a very long time.  Adding 15,000 entries took over 180 seconds.

The second way is to use the"Add Multiple Items to End" invoke method.  This took over 20 seconds for 15,000 entries.

The third way is to programatically respond to the user expanding an item in the tree and populating only as necessary.  I assume that this is fast, but it seems like a lot of work to do every time a tree control is used that could have a lot of items. Maybe LabVIEW could improve performance by using the third approach internally for the programmer. 

Currently I am hesitant to use a tree control because of performance.  LabVIEW is a great product, and making the tree control perform better would improve LabVIEW even more.