LabVIEW Idea Exchange

cancel
Showing results for 
Search instead for 
Did you mean: 
0 Kudos
ouadji

Ignore Errors Inside Node

"Ignore Errors Inside Node" should be disabled (greyed out) when the Property Node has only one property.

in my opinion, i think that be able to select this option with only one property does not make much sense.

With only one property, this option should be greyed out.

 

SR3.png

6 Comments
Norbert_B
Proven Zealot

Why should the property node differ?

What if the developer has two properties, sets that option and then removes one of the properties? Should the node keep the setting or remove it? Do you think that your answer regarding that question matches the opinion of all other developers around the world?

 

Sorry, but no kudos this time....

 

Norbert

Norbert
----------------------------------------------------------------------------------------------------
CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.
ouadji
Trusted Enthusiast

Why should the property node differ?  To match with its own internal workings.

 

...Should the node keep the setting or remove it?  remove it.

 

Do you think that your answer regarding that question matches the opinion...

 

I don't know, but if others take a different view,  it does not prevent me from giving mine.  Smiley Happy

 

no kudos this time....   not every time !   Smiley Wink   

 

thank you Norbert   Smiley Happy

 

 

AristosQueue (NI)
NI Employee (retired)

This is a bad idea. I very rarely say that firmly on the Idea Exchange, but in this case, it highlights an issue that LabVIEW regularly deals with -- an option that is sometimes settable and sometimes not.

 

Suppose you had a property node with 3 items and you enabled the setting. Then you shrunk the property node down to 1 item. Now it is grayed out. Is the option left on? I suspect the idea author would say "no", otherwise it defeats the purpose. So LV should at the very least draw the property node with the option turned off.Ok... but is the option *actually* turned off or does the node remember that it was once turned on? Let's say you make it actually turn off. Now the user grows the node back to two items -- they may not notice that the setting was toggled. This actually happens a lot with these kinds of "LV will toggle this off for you" systems, so we try to keep them to a minimum. So we leave it on, let the node remember the setting. Then you get the problem of the node being copied and then grown -- happens a lot with property nodes -- and now you have a very rarely used setting invisibly propagating and possibly being used without anyone realizing it.

 

After many many years of encountering this scenario many times, LV team has concluded that the ideal solution, when  possible, is exactly the current behavior -- leave the setting in play in the cases where it has no impact and let users turn it on or off as needed. We do not always follow this policy -- sometimes because we consciously decide against it and sometimes because a new hire puts in a new feature and no one notices that he hasn't learned this lesson -- but in general we try to follow it.

JordanG
NI Employee (retired)
Status changed to: Declined
ouadji
Trusted Enthusiast

@AristosQueue :

 

 

Thank you for your explanation.

I better understand the problem that may arise.

This way of thinking is logical, and on second thought, you are right.

JÞB
Knight of NI

ALTHOUGH! the feature is commonly miss-understood.  The help is clear and, the feature is clear in implementation.  But I've seen more than one highly experienced LabVIEW developer confused by it.

 

This sounds like a good case for an example!  One that throws errors (and multiple errors within various argments) within a property node.  Tossing controled errors from selectable arguments within an existing p-node while reconfiguring the ignore property has me itching my scalp just a bit though I must say.....

 

Norbert or Stephen might have better ideas on how to implement a new example to demo the feature.


"Should be" isn't "Is" -Jay