LabVIEW Idea Exchange

Classes? OOP? ... Huh?

Even if you don't (yet) work with LV classes, you may have noticed that they are starting to become increasingly widespread in the LV world. In fact, the excellent new Actor Framework that ships with LV2012 relies heavily on classes. LV classes are great but they can impact on your performance as a developer as your application becomes larger. I'd encourage everyone to click the magic KUDOS button for this idea, since classes will likely affect us all sooner or later!

The problem:

Most class-based architectures contain some degree of linking. One form of linking is inheritance where parent-child relationships are implicitly defined, and another form of linking arises from nesting libraries where classes (e.g.) are placed inside other libraries.

Unfortunately as the linking increases in a project, the IDE starts to become very sluggish! Those who have worked on mid-sized class-based applications know the symptoms:

• Opening the "class properties" window takes 10 seconds or more
• Renaming a class brings the editor to a standstill

For many projects these symptoms are a minor annoyance, but as your project grows they can become a serious impediment to productivity. Why should it take over 30 seconds to modify a class's inheritance?!

Obviously careful design can reduce linking to some extent, but that just postpones the pain. The reality is that all class-based projects start to suffer from these symptoms once they reach a "resonable" size.

The idea:

Improve the responsiveness of the LV editor when working with classes.

• Highly repetitive tasks such as editing a class library's icon deserve a snappy response from the IDE, regardless of how many classes I have loaded!
• Modifying inheritance is a fundamental operation. It should be quick and easy! (See this related idea)
• Placing classes in libraries promotes good project organisation. It should *not* bring the editor to a grinding halt!

Credits:

Others have written about this topic well before me. Here are a few relevant discussions:

• http://lavag.org/topic/15199-editing-an-existing-class/
• https://decibel.ni.com/content/thread/14907?start=15&tstart=0

Feel free to link more! 

Often when I want to look at the structure of a complex data type containing nested typedefs, I find the data type description in the Context Help quite heavy/verbose.

For example, could you tell at first glance how many levels of hierarchy there are in this data structure ?

Well, actually there are 5 levels (including the root cluster), but this is obfuscated by the unnecessary levels added by typedefs.

The description could be much more concise:

Here is an alternative that keeps the typedef type descriptions and appends them after the typedef name. However I'm not sure about this one because it could create description texts that are too long to be displayed in a single line:

Also for the configuration, it could be an option in "Options > Environment" and/or a button in the Context Help:

What are your thoughts ?

Raphaël.

I would like to have the ability to make a Front Panel background transparent without making the whole window transparent (where the later is currently possible through property nodes).  This one item would expand the UI possibilities.  It would allow for the creation of Front Panels that seem to be borderless similar to many splash screens, about screens, and gadgets.  Below are some industry examples:

Adobe Splash Screen (No border, has shadow, not square)

  Microsoft Word 2010 Splash Screen (No border, rounded corners)

 Resource Meter Windows Gadget (No border, specialized graphic)

Windows Media Center Gadget (Empty-transparent space between two UI elements)

Hello,

As shown in below image we can see that, if I index numeric array and wire it with any of the node from numeric function it gives un-aligned wire whereas as same process if I use Boolean function at output of index it gives well aligned wire.

So due to this numeric function node wire to index out terminal makes our code with full of wire bends which is not as per NI LabVIEW coding standards also.

So here, I want to draw attention for NI, to do some correction to specific numeric function nodes so we can make neat and clean code in LabVIEW.

It would be useful if QuickDrop supported a way of dropping multiple instances of the same item in one go. It is sometimes desirable to do so. For example, we may want to drop three numeric constants in one go.

The QuickDrop action above would result in three numeric constants being dropped, as seen below.

Selecting an error wire, then executing the sequence: Ctrl+Space >> typing "rn" >> increasing the Number of Items to x3 >> Ctrl+I would result in three property nodes being inserted into the error wire, as seen below.

Notes

• It would be great if the multiplier could be typed as part of the QuickDrop search string. For example, typing "rn x3" or "x3 rn" would then drop or insert three property nodes. This would mean that the whole action can be done from the keyboard, which would be quicker. However, it seems difficult to implement due to the search string needing to be intelligently split into two parts.
• Perhaps a much easier implementation that would be almost as quick would be to type "rn" >> press Tab (this would tab to the "Number of Instances" control) >> type "3".

Thanks

NXG had a neat feature I miss in LabVIEW 20xx and that is resizable nodes for operations like OR, AND, and Add.  There are other nodes that could benefit from this too like subtract and multiply, but here is the idea.

I'm aware that the Compound Arithmetic is a resizable node that covers the examples I have here.  But often times I will start with just two inputs so I'll use the OR, then later on I'll need to add a node and now I need to replace it with the Compound Arithmetic and then add the other inputs.  If the suggestion is to just use Compound Arithmetic, then why even have an OR node?