LabVIEW Idea Exchange

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.

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

In my project, I wanted to set the cell color in excel as red during a failure condition. But to my surprise I found that the color was set to blue and NOT red.It took me a long time to understand that the hexadecimal values for the color constants are different in Labview and MS Excel.

I wonder why the color constants are not standardised, when Labview supports features like ActiveX controls. 

While creating a labVIEW vi directly from vision assistant, the buffer needs to be manually allocated.

 I have faced this minor hitch of changing the palette to actually view the image when i am starting with a color image and ending with a binary image. Automatically allocating optimized buffer for image destination will save some time as well as avoid "Incompatible image type error". The problem will get multiplied when you have created a subvi and have used a "imaq extract function" before this. The buffer will automatically get overwritten. Hmmm I know this is a luxury but still.......................