Change runtime error to broken VI if using Value or Value (Signaling) for latched boolean

[JB]

As expected, the use of a Value or Value (Signaling) property for a button with a latch mechanical action will generate the error 1193 when executing this code.

Run this code ? Yes, the Run arrow is unbroken in this case. I suggest to break it... like when trying to write to a local variable of such a button.

[Mr.Mike]

I suppose we could do this for bound property nodes (i.e. property nodes that are connected to a class), where we know at compile time whether setting the value will generate an error.  However for an unbound property node (where you wire a reference in), we'd still need to generate an error.

I think that would be confusing (and this isn't the shelter our users argument) because in some cases you can compile, and in some cases you can't.  Then when you fix your problem and can compile you can still get the same error setting the same property to the same value just because you used/didn't use a convenience feature (bound property nodes).  Although compile-time errors are much preferred to run-time errors, I think this is a case where it makes more sense to have the error universally generated in one place.  Since local variables are inherently bound to a control, I think it makes sense that we break the VI.

(I don't have a strong opinion.  I'm just commenting on the consequences)

[G-Money]

Changed Idea name to reflect that the main idea is to change the runtime error if you use Value or Value (Signaling) for a latched boolean object

[JB]

Thank you very much G-Money. As you have noticed, English is (unfortunately ?) not my mother tongue !

[Darren]

Any idea that has received less than 3 kudos within 3 years after posting will be automatically declined.