LabVIEW Idea Exchange

Top Authors

User

Kudos

Post an idea

Make "Disabled and Grayed" Usable

View All (4)

When trying to make a complex GUI using the tree control, it is often desired to set specific colors and fonts to individual rows, columns and cells within the tree.

A good example of this is a test result dataset where you want to have a tree that has items for each test and sub items for each measurement within each test, then have an additional column that displays the result for each measurement with a colored background, like this:

Unfortunately the method 'Add Multiple Items to End' has a limited number of attributes you can set when adding a set of data:

The only solution is to add all your items and then loop through each item and set the required cell attributes individually:

Even with setting 'defer updates' on while doing this, the process is painstakingly slow for large datasets.

The solution would be to add an array of clusters element to the cluster in the 'add items' method that would allow the setting of these extended attributes of the tree. This way, the data could be processed in the assembly code much faster than setting each element in a for loop, as is required now.

This would make the tree control much more useful. This should not be hard to implement and should be easy to make backward compatible. It would just require expanding the datatype that stores the tree contents to include this extended data.

View All (4)

(As already hinted here, I think this deserves a seperate idea).

Property nodes have many items that accept color data (cursor color, plot color, bg color, etc). When right-clicking these and "create constant|control|indicator", we get a generic U32 type. Instead, we want a colorbox! Even more complex color structures, e.g. (colors[4] of a boolean) should have colorboxes as the innermost elements.

In all instances I have ever used these properties, I ended up replacing the U32 with colorboxes for code readability and simplicity.

Idea: when creating an input or output (constant, control, indicator) on any color property, we should get a colorbox (control, constant, indicator) instead of a plain U32 numeric.

Persistent font Settings

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

View All (5)

Better Palette Set Editor

The palette file editor is in desperate need of a make-over !

It shouldbe possible to:

Add libraries/classes/projects to a palette and create a whole tree of menus automatically
Edit individual vi icons as well as palette menu icons
Rename (i.e. Save As...) a palette file and have the refering links renamed optionally (a bit like the save as for a vi dialog).
Exclude files and directories according to user defineably patterns when synchronising to disk
Copy/Paste palette entries rather than just move them

Probably some other things, but that's good enough for starters.

View All (2)

New build option: Service

It is fairly common to build applications in LabVIEW that are useful to run as a service (monitoring software e.g.) , however to do so today you need to "cheat" and use srvany, and write and run batch files to get it installed.

It would be great if we could build real services, and the installer would take care of the installation process. You could even have a nice template for services with an accompanying user interface client, with notification icon and everything.

LabVIEW everywhere...Not just on different targets, but in every part of the system. 🙂

This one of my very old ideas and goes all the way back to InfoLabVIEW. I recently got reminded in this thread to write it up as an idea. You might have heard it before. If not, read it :D)

Currently, an output tunnel gets the default value for the given datatype if "use default if unwired" is enabled and a case executes where it is not wired. Recently, we also got the "linked tunnels" feature, which is more like an editing assistant.

Many times we have a big stack of cases but the computation of many outputs is shared by many cases, maybe with one or two notable exceptions. 😉 It would be cool to be able to define this shared "default" code only once so it is executed unless we create an exception case.

My suggestion is to have a new, special case that allows us to define the output of each tunnel for cases where it does not receive an overwriting input.

The image shows a few possibilities for an event structure (same applies for all other relevant structures).

A: A reference is wired across by default. We don't need to wire across any other case.

B: Nothing is defined, so it acts like today. This is the default, so everything is automatically backwards compatible with existing code.

C: A number is incremented with each iteration unless we overwrite in a specific case

D: The default output is based on the operations of several inputs.

E: If a tunnels is unwired, we get NaN (or whatever we need) instead of zero. For I32 me might want -1, for example.

F: Same as A. This is similar (but not exactly the same) as linked tunnels. (I.e. It also applies to existing unwired cases)

G: This tunnel is defined in all cases. If we add an unwired case later it would act like B.

H: (not shown): certain global event terminals (e.g. time) should also be available in the "default definition case", because we might want to utilize it for a default output.

Downconversion would be somewhat messy. It would probably need to wire the relevant default operations into all cases where an output is not wired, keeping the functionalty the same.

Message Edited by altenbach on 07-11-2009 10:45 AM

View All (2)

Whenever we create a constant (or control) on a partially connected function, we get not only the same datatype (good!), but also the same array dimensionality (often not so useful).

In the vast majority, I want do do some uniform operation on the entire array, so a scalar control or diagram constant would be much more desirable. I usually end up creating the array constant, then pulling it out of the container, hook it back up, and delete the container. This guarantees the correct datatype (I32, DBL, CDB, etc).

(It is even more tedious to place a diagram constant from the palette and then remember the datatype and adjust accordingly).

IDEA:

When creating a control or constant, and it would result in an array, I would prefer to also have a scalar option.

This little move illustrates it in the case of creating a diagram constant. It should apply equally to controls.

Message Edited by altenbach on 07-11-2009 09:51 AM

View All (1)

Context Help and Quick Drop

View All (2)

Better support to UI localization

If you want to distribute your application to several countries, you must find a way to localize the UI.

There are a lot of threads in the forum, documents in the NI Developer Zone, etc... but all of them are based on the Export Strings/Import Strings functions.

I think that this approach has some problems:

difficulties in changing languages on the fly (during EXE execution)
how can you switch between English and Chinese (or Chinese and Russian), for example?

I had this kind of problems in the past also with CVI, but with the new CVI 9.0, a very interesting, powerful and easy solution has been implemented.

Basically it uses a new property called "charset" that you can set for all your panel, but also for every control of your UI.

Playing with this property you can also have several different languages (mixed single-byte and multi-byte too) on the same window: and it doesn't matter how the language settings of your OS are!!!

Don't you think a localization approach like the CVI one would be nice?

And an Integrated Localization Utility (like CVI) should be appreciated too...

vix

View All (5)

View All (6)

Adding CONSTs to LabVIEW

I would love it if LabVIEW had logical constants, similar to what other languages have. Basically, a logical constant is similar to a variable (i.e. it's a value which is assigned a name), but its value is set at compile time. CONSTs help code readability.

In LabVIEW, a CONST would basically be similar to a global variable, with two differences:

1. It would be read only (so no race conditions, everyone can relax).

2. Changing the value on the front panel of the CONST VI will automatically require the user to save the VI, without needing to manually set the new value as the default.

Today, you can implement these in LabVIEW using all kinds of methods, but non of them is as convenient as this.

View All (4)

View All (6)

Here's a very fundamental User Interface concept that LabVIEW lacks:

When you press and hold an increment or decrement button on a numeric/ring/slider...etc..., the rate at which the value changes is constant: painfully slow. Typically, in other applications, button presses will increase the rate of change of the number proportional to the amount of time held, and if you hold it for 5 seconds or so that sucker is flying.

We want the same native behavior for increment/decrement buttons in LabVIEW, but we want it to be configurable. Consider a Property Node that defines a Lookup Table for the velocity profile of the increment:

The way the above code is read: For 0<t<1000, the control only moves at 1unit/sec. For 1000<t<3000, the control moves at 10units/sec. For 3000<t<5000, the control moves at 100units/sec. Another (more difficult?) way to define the velocity profile is to provide the velocity profile vs. time as a formula.

Of course, while the "typical" profile would start off slow and accelerate, I'm sure the ability to create unique accel/decel profiles would give incredible control for some awesome, one-of-a-kind User Interfaces.

(As a side note, if LabVIEW simply implements a fixed acceleration rate that was non-configurable, I will still be frustrated and still take the XControl route.)

I'm sure someone can think of a better, more intuitive implementation, but the concept remains:

For a press-and-hold on Increment/Decrement buttons, the control should increase its rate of change proportional to the amount of time it has been held, as defined by the programmer.

View All (4)

LabVIEW Idea Exchange

Make "Disabled and Grayed" Usable

Tree Control method 'Add Multiple Items to End' should allow for greater customization to tree contents.

Color properties should default to colorbox data

Persistent font Settings

Better Palette Set Editor

Don't be ashamed of the In Place Element Structure (put it on the Structures Palette)

New build option: Service

User Events are used for Synchronisation too

Colour box Constant menu position is a bit unusual

A better way to define the output of unwired output tunnels

Create constant|control should allow scalar option

Replace/Insert/etc context menu should show palette for wire element type as well as Array Palette

Report generation toolkit for OpenOffice

Context Help and Quick Drop

Better support to UI localization

Add the possibility to search for shared variables in a project an in VIs

Adding CONSTs to LabVIEW

Use standard Windows keyboard shortcuts to change font styles

Allow Increment and Decrement Buttons to have Adjustable Acceleration Rates

Visual Aides - Numeric Separators