LabVIEW Idea Exchange

When I use an event structure, the case I use about 99% of the time is "Value Changed".  This is a bit of a pain since it is alphabetically at the bottom of the list, so I have to scroll down the list every time to select the event.

 

Since I suspect most people use this event the most, I would like it to be the default value when defining an event.  This way, I could just select the control and be on my way!

 

Bruce

As mentioned here, "I lost count of the times where I have a cluster or enum constant that I want to make into a type def and have to first change it into a control, switch to the FP, and then select customize" - it'd be great to be able to right-click on a constand (like a cluster) on the block diagram and select Advanced -> Make Type Def (of course, you'd need to save the type def somewhere).

How many times have you found yourself entering items in an array, typing merrily along, only to have to switch back to a mouse to click on the next element and type it it.  I suggest that Alt-Enter complete the current entry and move to the next array element.

 

This idea proposed using the Tab key, which collides with manual tool changes.  Shift-Enter was also proposed, but it collides with the ability to move to a new line in strings and to add another element to a enum/ring.

 

I propose using Alt-Enter to advance to the next array element:

Compared to plain terminals and references (for example), local and global variables are too big. They waste way too much space on a bulky frame.

 

In my applications, local variables often come in large groups (e.g. if I need to write values from a file to a group of controls inside a case to load a different default set for the controls) and I tend to partially overlap the locals to save diagram space. I would prefer a more economical design, e.g. as shown on the right.

 

Globals could have that little globe (not shown).

 

I am not sure if we really need to encode read vs. write in the frame thickness like for terminals, but it could easily be done by making the frame of the "write" versions thinner (same outer dimensions). I think the little triangle is enough to show the direction.

 

Provide a growable merge errors.

 

Replace This:

By This:

 

 

Note : I have already done this with XNODE. But since XNODE are not available, I can't use it in my project.

It has been mentioned before (here, and here, and here) that there are some problems with the connector pane. Let me add my suggestions. Does the image below ring a bell? WHAT GOOD ARE ALL THOSE CONNECTOR PANES FOR?

 

 

I suggest the following view:

 

 

The "Define New Connector Pane" will allow you to contrive custom panes to suit your fancy. It could have templates of the current connector pane collection. Below is a pane you could create with the new editor (I would suggest combining the Icon Editor with the Connector Pane Editor!!!!). The only constraints that need to be imposed on a connector is that it is rectangular and touches the edge of the icon. Otherwise, you can make it however big you want it (for all the myopics out there like me!), and wherever you want it.

 

 

Two new concepts are introduced above: empty space, and the ability to land a wire NOT directly in the center of the connector. Placing the landing as close to the center as possible would alleviate the current problem of the "gapped wire" that does not touch slim icons (look at gap on top input and the output).

I always wanted to have a table or a (Multicolumn) Listbox that allows me to integrate drop down menus (or other elements)

 

Here's an example from another software (Agilent Benchlink datalogger) which illustrates this quite well:

 

 

 

One could realize something similiar by creating his own Array of cluster, but this is cumbersome and very uncomfortable to change/maintain, mainly because of the difficult selection of all the control frames which are placed one over the other...

 

Functionality good, layout questionable...             Layout similar to the picture above, but not very flexible (not an array) and "hard to handle"

        

 

 

PROPOSAL:

Add a new type of list control, behaving similar to a Array of cluster control, where different types of already existing controls can be selected as it's elements, and where those controls are placed next to each other without those annoying and real-estate consuming spaces between them

 

A-T-R

I really like having two different default locations for my terminal labels.  What I do not like so much is that I still end up dragging a lot of labels around after changing a control to an indicator or indicator to control.  I would like it if the label location was automatically moved to the default position when the direction of a terminal is changed. 

 

You could get fancy and only move it if it is currently in the default location, I'd prefer it to always be moved.  And I am not interested in the Quick Drop shortcut here.  I do not want a quick way to clean up the mess I do not want the mess made in the first place.

 

When loading a VI where some or many of the VI's are missing (like a forum post where the person used 3rd party driver subVI's you don't have or used numerous subVI's and typedef's that they did not bundle into their attachments) you have to click ignore on each subVI as it comes up with the dialog box as it searches for it on your system.  If there are only a few such subVI's, it is no big deal.  But some people will be missing dozens of VI's, and you have to continually click ignore over and over again until the main VI loads broken.

 

It would be good if that dialog box had an Ignore All button, so that once you come across the first subVI it can't find, it will ignore it and all other subVI's it can't find.  Then the main VI can load in it broken state in just one or two clicks.

Add a slider on the toolbar which would allow changing the zoom level on the diagram. This should also be controllable more easily (for example, by using shift + mouse wheel scroll).

 

Personally, I want this less for zooming out and more for zooming in. It's sometimes convenient to have a larger display of a specific area.

 

I know some people feel that a zoom is a terrible idea because it will encourage people to create huge diagrams. Personally, I doubt that (since you can't work on zoomed out code and zooming out and in repeatedly isn't that convenient), but I don't mind if people do that. It's their code (as long as I don't have to work on it later).

If people really insist, this can also be prevented by setting the maximum value of the slider to 1, so that people can't zoom out, but I doubt this would have any value.

 

The zoom should snap to 1 when you get near it and should center on the mouse cursor.

Let’s take the Value Changed from OpenG, This polymorphic as 30+ VIs to support all data type and array size up to 2D. But basically it’s the same VI for all data type.

 I think it could be a “.vip” and when you define the connector pane you select constraint of the possible data type that can be accepted.

LabVIEW  has a somewhat hidden feature built into the variant attributes functionality that easily allows the implementation of high performance associative arrays. As discussed elsewhere, it is implemented as a red-black tree.

 

I wonder if this functionality could be exposed with a more intuitive set of tools that does not require dummy variants and somewhat obscure VIs hidden deeply in the variant palette (who would ever look there!).

 

Also, the key is currently restricted to strings (Of course we can flatten anything to strings to make a "name" for a more generalized use of all this).

 

I imagine a set of associative array tools:

 

 

• Create associative array (key datatype, element datatype)
• insert key/element pair (replace if key exists)
• lookup key (index key) to get element
• read all keys
• delete key/element
• delete all keys/elements
• dump associative array to disk
• restore associative array from disk
• destroy associative array
• ... (I probably forgot a few more)

 

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.

 

 

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.

 

 

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.

Currently, the space constant looks very similar to an underline character, possibly causing confusion.

 

I think the icon could be made a bit more distinctive. Here are some alternatives I just made up. I would probably prefer (1) but I am open to any other suggestions. 😄

 

We always get endless confusion in the forums when looking a code images, because we never know if a string diagram constant in a diagram image is in normal, \-codes, hex, or password display.

 

I think we could avoid confusion and really enhance code readability if string constants (and possibly string controls and indicators) would indicat their format.

 

I would suggest something similar to the radix display of numerics.

 

Here's an example how the same string diagram constant could look like, depending on the selected dispaly format.