Community Nugget: Clear up your front panel a bit

[tst]

In the past, almost every single time I dropped an error cluster on the front panel to serve as an input to a subVI, I would get just a tiny bit annoyed.

Why is that? Because the cluster has the label "error in (no error)". That second part is just annoying. I know the default value is no error. It's obvious. I don't need it in my face with every single error cluster.

Well, luckily, there's a rather simple fix for this - just modify the original control which is dropped.

The controls can be found at

<vi.lib>\errclust.llb\Error In 3D.ctl

<vi.lib>\errclust.llb\Error In.ctl

Since I did this change I haven't looked back. Life is good. Birds are singing and the trees are green.

However, this change has to be done every time you reinstall LabVIEW. If you want not to have to do it ever again, go vote for this idea:

Get rid of the "(no error)" part of the error cluster

For a list of past nuggets, see here.

[Ben]

---

tst wrote:

In the past, almost every single time I dropped an error cluster on the front panel to serve as an input to a subVI, I would get just a tiny bit annoyed.

...

...

However, this change has to be done every time you reinstall LabVIEW. If you want not to have to do it ever again, go vote for this idea:

Get rid of the "(no error)" part of the error cluster

For a list of past nuggets, see here.

---

I kudoed it and want to take the next outrageous step* (Oh my! ).

Starting here and now we should STOP including the default value in the label!

1) It will prevent NI (if they follow the new rule) from putting that in the templates so we don't have to fix it as described above.

2) It will make our bundle/unbundle nodes smaller.

3) It will eliminate the need to change the name when we decide the default value should change.

Every control has a a tip strip and a help window that are well suited for recording the default value.

Now for you LVOOPers out there, imagine if you had method where you wanted the error cluster to be something other than "no error". If you stuck to the rule you would have to chang ethe label. You change the lable for that one method and all other Over-ride VI's will break because the names do not matchup.

So I say...

 we should STOP including the default value in the label!

 Can anyone provide a good reason why we should keep putting the default in there aside from some rule ? 

Ben

* Silly rules should be broken as often as possible!

[Matthew_Kelton]

I used to do this.  It has been a while, but there used to be something that caused me issues.  Some automated tool (VI Server?  TestStand?, I cannot remember) that complained that the input error cluster was missing because it expected it to be error in (no error).

Once I ran into that, I just used the defaults.  I agree that the default values in parentheses tend to annoy me, and I do not use them.

[Ben]

---

Matthew Kelton wrote:

I used to do this.  It has been a while, but there used to be something that caused me issues.  Some automated tool (VI Server?  TestStand?, I cannot remember) that complained that the input error cluster was missing because it expected it to be error in (no error).

Once I ran into that, I just used the defaults.  I agree that the default values in parentheses tend to annoy me, and I do not use them.

---

Thank you Matthew!

That make my point number 4

4) " Some automated tool (VI Server?  TestStand?, I cannot remember) that complained that the input error cluster was missing because it expected it to be error in (no error)."

So far I have recieved a couple of Kudos that I'll interprest as a yes and Matthew's reply as support for my suggestion to toos the silly rule.

Still looking for reasons to counter my suggestion.

Ben

[tbob]

Funny thing, I've been doing the same thing for years (deleting the no error in the label).  I just haven't complained about it.  I'm glad somebody spoke up. 

Long labels just waste space on the block diagram.  If you look at my past posted examples, you will see in almost every case that the error in label has been modified to get rid of that stupid no error part. 

Earlier versions of Labview did not have this label, it was simply error in.  I think the no error part was added in the same version that the error wire color changed from pink/white to yellow/black.  Maybe it was version 6.0, I believe.

[smercurio_fc]

---

Ben wrote:

I kudoed it and want to take the next outrageous step* (Oh my! ).

Starting here and now we should STOP including the default value in the label!

---

I agree! I rarely use them, though it means I'm violating the LabVIEW Style Guide:

Give controls meaningful labels and captions.

Details

The name of a control or indicator should describe its function. If the control is visible to the user, use captions to display a long description and add a short label to prevent using valuable space on the block diagram. For example, when labeling a ring control or slide control that has options for volts, ohms, or amperes, select an intuitive name for the control. A caption such as "Select units for display" is a better choice than "V/O/A". Use Property Nodes to change captions programmatically.

Use consistent capitalization, and include default values and unit information in label names. For example, if a control sets the high limit temperature and has a default value of 75 °F, name the control high limit temperature (75 degF). If you will use the VI with the control on multiple platforms, avoid using special characters in control names. For example, use degF instead of °F, because the ° symbol might not display correctly on other platforms.

For Boolean controls, use the name to give an indication of which state corresponds to which function and to indicate the default state. For checkboxes and radio buttons, the user can click the Boolean text of the control and the value of the Boolean control changes. Free labels next to a Boolean control can help clarify the meaning of each position on a switch. For example, use free labels like Cancel, Reset, and Initialize that describe the action taken.

The Context Help window displays labels as part of the connector pane. If the default value is essential information, place the value in parentheses next to the name in the label. Include the units of the value if applicable.

[Broken_Arrow]

Kudos. 

error in (no error) makes about as much sense as error out (perhaps error).

[tst]

---

Ben wrote:

Can anyone provide a good reason why we should keep putting the default in there aside from some rule ? 

---

Yes. The reason this convention exists is because the label (caption, actually, but that does not necessarily exist) appears as a tip strip when you hover over the input of the subVI. This is where it's useful to see the default value of non-required controls.

However, this exchange has given me a new idea:

Show the default value of controls in subVIs which aren't required in the tip strip

This will allow us to stop using the default value in parentheses, exactly as you wish, while keeping the advantage of seeing the value when it's needed.

[Broken_Arrow]

Speaking of labels, I have never liked the fact that Sub-VI terminals take on the Caption name and not the Label name, if a caption exists. I think it should be the label and that's that.

[TCPlomp]

---

Broken Arrow wrote:

Speaking of labels, I have never liked the fact that Sub-VI terminals take on the Caption name and not the Label name, if a caption exists. I think it should be the label and that's that.

---

Broken Arrow could yu explain that a little bit?

Are you in favor of the caption or the label?