Behavioral difference between Property Nodes vs. Local Variables

[JonathanLindsey]

I'd like to point out a difference in the way property nodes and local variables work in LV 2019 SP1.

Are they supposed to work this way and why

Please watch the attached video and inspect the attached VI. When I interact with the front panel in this particular way the property nodes and local variables are used side by side but consistently return different values.

[RavensFan]

I think you have essentially a race condition through the user interface thread.

• You have entered a new value in the control, but leave the cursor there, so you have not changed the value yet.
• You click on the scrollbar.  The mouse down action of leaving the string or numeric control is enough to trigger the event.  The local, which is not tied to the UI thread, is able to read the value, but it is still the old value.
• When you do the mouse up, then the value of the scroll bar changes. The UI thread is now freed up to execute the value property node, which is able to read the new value of the scroll bar.

[paul_cardinale]

Works OK for me.

[RavensFan]

---

@paul_cardinale wrote:

Works OK for me.

---

At first I thought it did too.  Then I went back and looked more closely at the video and saw that the OP was leaving the cursor in the string or numeric control which meant the trigger for the value change event on that control didn't occur until the mouse down on the scroll bar.

Then the value change of the scroll bar occurs upon the mouse of the the scroll bar.

Overall, this is a very odd way to program a user interface, relying on a value change event of a different control to determine when the value change of a scroll bar is transferred from one to another.

[rolfk]

There certainly is a difference between the two and it is expected and documented behaviour. The value property node always executes in the UI thread (as any other property node affecting a front panel control). It executes synchronously (the update is done during execution of the node) and is magnitudes slower than a local variable or terminal access as it involves thread context switches to the UI thread and back.

A terminal or local variable does not do thread switching, is much faster and accesses an intermediate databuffer that is only synchronized about 50 times per second with the front panel control.

Without strange use of the two the main difference is the execution speed. A value property write or read in a loop will seriously limit the loop iteration speed as it is very quickly dominant in execution time. For proper use in the event handling structure it should not cause to many problems but updating values of a control in a different event case for another control and use of other events than the value change event certainly could cause subtle differences. The main thing you should take from this is that the value property should be principally avoided when there are other means to access the control value, unless you know exactly what you are doing!

[JonathanLindsey]

Thank you RavensFan for better spelling out the problem.

I have attached a VI showing how I am naively implementing a scrollbar. The video shows me adding several elements, inserting the word 'hello' which works and then adding 'world' directly below 'hello'. However, I leave my caret in the string control and click the scrollbar arrow making the two words separate. The reason I want to use property nodes here is that I eventually want to make this a scrollbar library and I want to read the controls from inside subVIs which cannot be done with local variables.

If someone knows a better way to implement a custom scrollbar, that would be great! I am looking for more control in how it looks and behaves than a simple array indicator gives me.