LabVIEW Idea Exchange

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

Why not removing "Invalid" & "Closed" two values of FP.Open Invoke Node

Status: Declined

Any idea that has not received any kudos within a year after posting will be automatically declined. 

In LabVIEW Invoke Node FP.Openinvoke-node.png

we have a parameter "State" which can only be written.

This "State" parameter have six values: Invalid, Standard, Closed, Hidden, Minimized, Maximized

If we set the parameter as Invalid or Closed, we will get an error.

Why not removing these two values here?

13 Comments
tst
Knight of NI Knight of NI
Knight of NI

Because the state can also be read as a property and it's an enum - the enum has to have all the values.


___________________
Try to take over the world!
Jack_Jim
NI Employee (retired)

Just maintain consistency with the enum output of the FP.State property node?protertity-node.png 

tst
Knight of NI Knight of NI
Knight of NI

Why not? Consistency is important. It becomes even more important if you were to use both the property and the method together, because then the enum values would not match.


___________________
Try to take over the world!
Jack_Jim
NI Employee (retired)

I agree consistency is important, however, if we use this method: invoke-node.png

Invalid and Colsed, two enum values, would be useless. We can not set "State" parameter as these two values, which makes our customers confused.

RavensFan
Knight of NI

Then that fact should be noted in the documentation of the property node that it is invalid to write those two states to the property.  I wouldn't change the enum.

SteenSchmidt
Trusted Enthusiast

@RavensFan: It is noted in the documentation already.

 

/Steen

CLA, CTA, CLED & LabVIEW Champion
Darin.K
Trusted Enthusiast

It would be kind of cool if those two values were disabled automatically in the created enum control/constant.

Jack_Jim
NI Employee (retired)

@Darin.K: Yes, I really agree with you.

tst
Knight of NI Knight of NI
Knight of NI

Another possibility for implementing something like this would be if LV had sparse enums - then this list could display only some of the values and the enums would probably still match.


___________________
Try to take over the world!
AristosQueue (NI)
NI Employee (retired)

> It would be kind of cool if those two values were disabled automatically in the created enum control/constant.

 

No, it wouldn't be cool. Because then someone would ctrl+drag their enum constant somewhere else and complain that it was disabled. Or, if we made them reenable on copy, ctrl+drag it to another FP.Open and complain that it *wasn't* still disabled. And so on.

 

It would not be cool. It would just be weird and annoying.