Remove the "(error in)" text from default error controls

[gleichman]

QUOTE (Aristos Queue @ Feb 25 2009, 11:15 AM)

Shouldn't error terminals be moved -- on all nodes -- to be the top terminal of all nodes? , wouldn't that be a better strategy?

I like this idea!

I would like to see the default label "(no error)" part of the error in go away.

[crelf]

QUOTE (gleichman @ Feb 25 2009, 04:56 PM)

I would like to see the default label "(no error)" part of the error in go away.

I would only support that if it were replaced by some other method of easily seeing the default of controls.

[jdunham]

QUOTE (gleichman @ Feb 25 2009, 01:56 PM)

I would like to see the default label "(no error)" part of the error in go away.

It takes about a minute to go into C:\Program Files\National Instruments\LabVIEW 8.6\vi.lib\errclust.llb and remove the annoying "(no error)" part of the label (don't forget to fix both the classic and the 3D version). That's just about the second thing I do to a fresh copy of LabVIEW after turning off 'Lock Automatic Tool Selection', 'Automatic Wire Routing', and AutoGrow.

[Grampa_of_Oliva_n_Eden]

QUOTE (jdunham @ Feb 25 2009, 07:07 PM)

It takes about a minute to go into C:\Program Files\National Instruments\LabVIEW 8.6\vi.lib\errclust.llb and remove the annoying "(no error)" part of the label (don't forget to fix both the classic and the 3D version). That's just about the second thing I do to a fresh copy of LabVIEW after turning off 'Lock Automatic Tool Selection', 'Automatic Wire Routing', and AutoGrow.

:worship:

Same routine here but I did NOT knw about the llb.

Ben

[PJM_labview]

QUOTE (jdunham @ Feb 25 2009, 04:07 PM)

It takes about a minute to go into C:\Program Files\National Instruments\LabVIEW 8.6\vi.lib\errclust.llb and remove the annoying "(no error)" part of the label (don't forget to fix both the classic and the 3D version)...

I actually do not mind the "(no error)", but I do mind the size of the error cluster. I change them back to the size they use to be in older LV version (significantly smaller) suing the same procedure Jason described.

PJM

[jdunham]

QUOTE (PJM_labview @ Feb 26 2009, 09:01 AM)

I actually do not mind the "(no error)", but I do mind the size of the error cluster. I change them back to the size they use to be in older LV version (significantly smaller) using the same procedure Jason described.

It's not such a big deal on the front panel, but I believe its removal makes the Context Help window (Ctrl-H) look a lot better. I'm fine with default values in parentheses when they are useful, but when they don't add any information, then they shouldn't be there. Maybe the original idea was that first time users might think that wiring anything into that input would signify an error, but it's more likely that "it seemed like a good idea at the time".

[crelf]

QUOTE (jdunham @ Feb 26 2009, 01:10 PM)

I'm fine with default values in parentheses when they are useful, but when they don't add any information, then they shouldn't be there.

That's a really good point. I only use the default value in parentheses if the default value of the control isn't the default value of the datatype.

[jdunham]

QUOTE (crelf @ Feb 26 2009, 10:26 AM)

That's a really good point. I only use the default value in parentheses if the default value of the control isn't the default value of the datatype.

Well it's also fine if the default needs clarification or has a special meaning like

filter coefficient(0:no filtering)

overwrite?(F:Append to file)

While I'm on my soapbox, making inputs "required" is a really good thing, and for the most part, required inputs don't need to have their defaults mentioned at all. But that has the same exception, where you may need to clarify a special interpretation of the default value for that data type.

[crelf]

QUOTE (jdunham @ Feb 26 2009, 01:47 PM)

Well it's also fine if the default needs clarification or has a special meaning like

I was thinking "I'll post a reply agreeing with that", but by the time my browser came up I think I'd changed my mind

I agree in principle that clarifying meaning is a good thing to do, but I'm not sure I agree with the examples you gave. I, of course, don't know the examples intimately, but here goes:

• filter coefficient(0:no filtering) <- if this is an input to a VI that filters, then you shouldn't be using this VI at all if no filtering is required. Make a decision outside of it and case it out if not required. Otherwise, all you're doing is moving that case decision to inside the subVI, which is hiding functionality, or, in this case, non-functionality
  
• overwrite?(F:Append to file) <- Either you're overwriting something or you're not - that's why it's a Boolean. I think it you want more options than that then use a datatype that allows for more than 2 selections (like an enum, since it's a choice between more than 1 textual-based things).
  

Sorry about getting on my soapbox, but I've never found where this sort of thing couldn't have been replaced with more intuative design.

QUOTE (jdunham @ Feb 26 2009, 01:47 PM)

While I'm on my soapbox, making inputs "required" is a really good thing, and for the most part, required inputs don't need to have their defaults mentioned at all.

I sure hope there's room on your soapbox for me too The only time I'd want a default mentioned when a connector pane element is required is when it's being run as a top level VI and it calls the "reint to default" method somewhere. We need to be mindful that it's not the control that we're making required, but the connection to it when it's used as a subVI.

[jdunham]

QUOTE (crelf @ Feb 26 2009, 11:50 AM)

I was thinking "I'll post a reply agreeing with that", but by the time my browser came up I think I'd changed my mind

Well I agree with you! :thumbup: My examples were just off the top of my head, since I have (*gasp*) other work to do.

The 'overwrite/append' example is straight from the old file I/O VIs and I have to say, the the new version that always overwrites is a big step backward (getting off topic...)

I would agree that if an input requires a lot of explanatory labeling, there's probably a bad design somewhere around there.

What this thread is really about is that words that add no extra value should not be on your VIs, and I get peeved by style guides that apply those kind of rules like "Always put the default value in parens in the label" or "always make inputs required rather than recommended" or always use "error in/error out" [even when it's totally unnecessary].

[crelf]

QUOTE (jdunham @ Feb 26 2009, 03:50 PM)

What this thread is really about is that words that add no extra value should not be on your VIs, and I get peeved by style guides that apply those kind of rules like "Always put the default value in parens in the label" or "always make inputs required rather than recommended" or always use "error in/error out" [even when it's totally unnecessary].

I'm totally with you - when talking about style, we should always use words like "guidelines" or "recommendations", and never "rules".

QUOTE (jdunham @ Feb 26 2009, 03:50 PM)

My examples were just off the top of my head, since I have (*gasp*) other work to do.

Me too - I've spent far too much time on non-billable stuff today, so can everyone stop posting such interesting and thought-provoking stuff?

crelf out.

[jdunham]

QUOTE (crelf @ Feb 26 2009, 01:18 PM)

Me too - I've spent far too much time on non-billable stuff today, so can everyone stop posting such interesting and thought-provoking stuff?

Awww c'mon. You're almost at 4000 posts!

[crelf]

QUOTE (jdunham @ Feb 26 2009, 05:46 PM)

Awww c'mon. You're almost at 4000 posts!

Well look at that... It seems like yesterday when I joined

[LAVA 1.0 Content]

QUOTE (jdunham @ Feb 26 2009, 01:07 AM)

It takes about a minute to go into C:\Program Files\National Instruments\LabVIEW 8.6\vi.lib\errclust.llb and remove the annoying "(no error)" part of the label (don't forget to fix both the classic and the 3D version). That's just about the second thing I do to a fresh copy of LabVIEW after turning off 'Lock Automatic Tool Selection', 'Automatic Wire Routing', and AutoGrow.

The fun thing is, you can create an OGP file (either with VIPM or OpenG Package builder) to overwrite that specific llb, just take the OGP's with you run VIPM and tada.

Ton

[Yair]

QUOTE (crelf @ Feb 26 2009, 09:50 PM)

filter coefficient(0:no filtering) <- if this is an input to a VI that filters, then you shouldn't be using this VI at all if no filtering is required. Make a decision outside of it and case it out if not required. Otherwise, all you're doing is moving that case decision to inside the subVI, which is hiding functionality, or, in this case, non-functionality

Well, I happen to disagree with that one. The whole point of a subVI is encapsulating functionality, so why put a case structure around every single instance where I wouldn't want to execute the code? This takes time, takes space, creates noise and actually hides the functionality more IMO, since you have to look inside the other frame to make sure nothing happens there. You're not hiding the functionality if you say "NO filtering" in your input.

The real problem here is using a numeric instead of an enum. I'm guessing that this comes from an old NI VI.