LabVIEW Idea Exchange

Community Browser
About LabVIEW Idea Exchange

Have a LabVIEW Idea?

  1. Browse by label or search in the LabVIEW Idea Exchange to see if your idea has previously been submitted. If your idea exists be sure to vote for the idea by giving it kudos to indicate your approval!
  2. If your idea has not been submitted click Post New Idea to submit a product idea to the LabVIEW Idea Exchange. Be sure to submit a separate post for each idea.
  3. Watch as the community gives your idea kudos and adds their input.
  4. As NI R&D considers the idea, they will change the idea status.
  5. Give kudos to other ideas that you would like to see in a future version of LabVIEW!
Top Kudoed Authors
cancel
Showing results for 
Search instead for 
Did you mean: 

Do you have an idea for LabVIEW NXG?


Use the in-product feedback feature to tell us what we’re doing well and what we can improve. NI R&D monitors feedback submissions and evaluates them for upcoming LabVIEW NXG releases. Tell us what you think!

Post an idea

It would be nice if you could change a selected font style by using the standard windows (MS office) shortcuts, such as CTRL-B for bold and CTRL-U for underline.  This would save many mouse clicks.

 

I realize that many people don't use Windows, so maybe it could be customized in the .ini file or would be dependent on what OS your are running.

 

font styles.PNG

This is written as both an Idea and as a Community Nugget.

 

Did you know there exists a function that decreases code fragility when it comes to typecasting and type converting datatypes? It's called 'Coerce to Type', and I bet you've never heard of this function unless you have kept up with this conversation. Thanks to RandyP for creating that Idea which culminated in a 'public' release of the Coerce to Type function.

 

21195iD087EF25489F6CED

 

Since that post, I have become aware of potential risks/bugs I had been proliferating in my coding style. First, I will briefly describe my understanding of the difference between typecasting and typeconverting in the context of LabVIEW. Next, I'll show a few use cases where this node increases code robustness. Finally, it's up to you to Kudos this Idea so we get Coerce to Type officially supported and in the palette!

 

Simply, "type converting" preserves the value of a wire, and "typecasting" preserves the raw bits that express that value on a wire. These two concepts are not interchangeable - they perform distinctly different data transfer functions (which is why they show up on two separate subpalettes: "Numeric>>Conversion" and "Numeric>>Data Manipulation"). Then there's this new function: Coerce to Type. I think of it as a Coerce-Cast combo. The data input is first Coerced to the datatype harvested from the top input, and then it is typecasted to that type.

 

Dynamic event registration is sensitive to the name on the wire, and for documentation's sake it has historically been important to typecast the event source ref to achieve a good name. Well, typecasting refs can get you into trouble (ask Ben), especially if you change the source control type while forgetting to update your "pretty name" ref constant.

 

21187iA83D4F02211D2DCB

 

My next favorite example is when you need to coerce a numeric datatype into an enum. Sometimes it's impossible to control the source datatype of an integer, while it's desirable to typecast the value into an enum for self-documented syntax inside your app. 

 

For instance, take the "standard" integer datatype in LabVIEW - I32 - and cast it to an enum. You're going to get some unexpected results (assuming, you expected the *value* to be preserved). Consider the following scenario:

 

  1. You desire to typecast a plain integer '2' into an enum {Zero, One, Two, Three}, and after 45 minutes of debugging, realize "Typecasting" has hacked off 75% of the bits and clobbered the value. Drats!
  2. The enterprising engineer you are, you determine how to fix the problem with a deftly-placed "Coerce to U8". (This is one of the fragile errors I proliferated prior to learning about this node)
  3. Maniacal manager/customer comes along and says "I want that enum to count to 10k". Drats again. A datatype change from U8 to U16 for the typedef'd enum, and a lot of typing with the wretched enum editor. Finally, two hours into testing and wondering why the program doesn't work, you realize you also forgot to replace all of the Type Converts to U16 (this is the definition of fragile code: you change one thing, and another thing(s) breaks).
  4. Rockstar Programmer Epiphany: use Coerce to Type, bask in your robust code. You even enjoy data value preservation from floating point numbers.
21191iD3339D40A531F181
 
Finally, typecasting can generate mysterious failure modes at Run-Time, but Coerce to Type can catch errors at Design Time. This is especially helpful for references (see above), but can also prevent some boneheaded data gymnastics (see below). Whew! Saved by compiler type resolution mismatch!
 
21193iC698E122C5BE16AC
 
In short, now that you realize you need this function, I hope you will want to see it added to the Data Manip palette.
 
Penultimate note: Coerce to Type is neither a replacement for typecast nor any of the type converts!!! There are distinct scenarios appropriate for each of the three concepts.
Ultimate note: please check the comments section, because I expect you'll find corrections to my terminology/concepts from GregR, et al.

This is minor one but it bugs me every time.

 

I create a new control and forget to change the type from "Control" to "Type Def.".

 

If I'm lucky I spot it after I drop it for the first time on the BD but sometimes I have to replace quite a few instances after I spot the error.

 

While there might be usecases for a custom control without it being a type def I think that most users want to use type defs when using custom controls.

 

Therefore please make the default type of new controls "Type Def."

I have probed the water on the general LabVIEW discussion forum with mixed success regarding this idea (some laughing at it, some actually getting the point).

So here it is:

 

Allow creating a subVI from merely one or more selected WIRES (no other objects being selected). The usefulness of this is typically when you realize that you need to test some data before doing something with the data flowing through this (these) wire(s). You could drop a sequence frame on your diagram, force the wires to go through it and then create a VI from the selected frame, but that's some unnecessary work. I am not saying that's a very critical need but it would seem a natural feature of LV. Right now, if you select wire and choose "Create subVI", nothing happens...

As a side suggestion, since you want to create a VI that has exactly the same outputs as inputs, it would be VERY useful to have the connectors precisely aligned in the connector pane, even when the wires are zigzagging.

 

My 2 cts.

 

original.png

Event Sources can be time consuming in finding when you have lots of FP objects.

Like the idea with Right Click menu option on terminal to add Event Case if it is applicable. (Event Structure must exist)

 

Also it would be useful if we have option to search Event Sources in Edit Event Dialog Box. As you type the name of the terminal it sorts it self and display only names of event sources that matches.