Make the "Expression Node" and "Convert Unit" visually distinct

[altenbach]

As outlined in this post, the current identical look of the Expression Node and Convert Unit can cause serious miscommunications, since their functions are completely different.

I suggest that they are made to look different so we can tell immediately what we have.

For example the two results below are very different, even though the code looks absolutely identical if the labels are hidden.

One possibility would be to make "convert unit" a different default background color (example shown below), but there are probably even better suggestions. How about rounded corners (not shown)?

[X.]

Unless I am missing some very clever use of the Expression Node in which this has a utility:

I would suggest breaking the code when a non-sensical expression is entered in the Expression Node.

The code DOES NOT break if the string has no space. I'd say tag it and bag it.

[altenbach]

There is some usefulness allowing arbitrary variable names. "x" is too limiting. We might want to use "i+5" for an integer type, and "sin(theta)" when dealing with angles. It is just better self-documenting.

Any function should support the degenerate case where the input is returned unchanged, that's why an expression node containing only e.g. "x" is allowed and will do exactly that. Since any variable name is allowed, longer names are treated the same. Nothing wrong with that.

Excluding all allowed unit strings as variable names in expression nodes seems too restrictive to me.

[X.]

I understand. So OK, let's not break the VI.

I'll just note that an EMPTY Expression Node is also valid and it does return the identity result too.

Not a bug?

One of the things you omit to mention in your description of how much of a problem it supposedly is, is that one [the unit node] requires the sink (or the source) to have a unit (different from the source), whereas if you inadvertently insert instead an Expression Node between sink and source, the wire will be BROKEN. I'd say it is hard to miss:

In other words, that may not be such a major problem that a NI engineer needs to be adding a little cosmetic distinction on one of the nodes, instead of working on the vastly more irritating bugs or features that constellate LabVIEW.

But I guess that is just my opinon.

[Albert.Geven]

Hi

An expression node is doing arithmetic, while a unit conversion converts.

So maybe the unit conversion should show what comes in and what comes out.

The arrows are not needed, I don't see arrows in subvi connections either, so use that space to tell something about the conversion or arithmetic

[PaulG.]

I use both so infrequently I have never noticed this. These two primitives are aesthetically shoddy. It's like their implementation was an afterthought and rushed.

[Darren]

FYI, I CARed this exact issue years ago. The CAR number is 223245.

[altenbach]

Thanks Darren. I wasn't aware of that CAR.

[X.]

How would you?

🙂

[Darin.K]

> How would you?

http://forums.ni.com/t5/LabVIEW/Darren-s-Weekly-Nugget-04-26-2010/m-p/1119714#M494332

[X.]

I mean:

- know about a CAR

- track a CAR

- figure out what's been done about it (this one I can guess, though 🙂