Tab Control Bug

[MikaelH]

Hi

I guess many of you have encountered this issue with the tab control.

Is this a bug or something everybody knows about and always just manage to live with it.

The problem is that the Tab Control don’t always changes Tab when you programmatically changes is using a local variable, if you at the same time updates a control or indicator using the property node which is located on any of the tabs.

Why??

(LV 8.6)

//Mikael

TabTest.vi

[Dan DeFriese]

Wow that's wierd. Option 2 works with execution highlighting on. Which I generally associate with a race condition. So forced execution with an error wire and sequence structure and it worked.

TabTest.vi

[Omar Mussa]

I guess many of you have encountered this issue with the tab control.

Is this a bug or something everybody knows about and always just manage to live with it.

The problem is that the Tab Control don’t always changes Tab when you programmatically changes is using a local variable, if you at the same time updates a control or indicator using the property node which is located on any of the tabs.

Why??

(LV 8.6)

//Mikael

I think this is a bug that maybe nobody's been reporting? I've seen it for a while so I'm in that group (and it still exists in LV2009 as far as I have seen). My workaround -- you can use the Value.Signaling property and it seems to always update correctly. Just be sure that the Tab Value Changed event is not going to impact you negatively if you use this property.

[MikaelH]

I better report it so we might get it fixed until next NI-week :-)

I've always got my code working with some workarounds.

One way is to use the Property Node of the Tab Control when changing the value.

Sometimes I use a SubVI to change the Tab like this:

This also saves some Block Diagram Space.

But then I have to make sure the Tab is a Type Def and that can create some other issues.

Cheers,

Mikael

[Bobillier]

Hi

Have you test to put your tab update outside the event structure like this:

[Rolf Kalbermatter]

Hi

Have you test to put your tab update outside the event structure like this:

That is likely to work but has probably not the intended effect since the tab is now changed all the time independent of the event that occurred (or you have to make sure to wire out the correct (current) tab control value in all other event cases, for a real application!).

Using a value property for the tab control (or preferably a local for the string) seems a more logical solution here and since that executes in the UI thread it involves a context switch and is sure to avoid the optimization race condition that seems to be in place here otherwise.

Rolf Kalbermatter

[huotom]

Dear all, I change the Tab Control local variable with property node: Value, and it works.

And I seldom use local variable except for Path or boolean value.

PS: If we want the numeric value change event occures, we usually use the value(signal) property instead of value.

Thanks.

Tom.

Edited September 26, 2009 by huotom

[Rolf Kalbermatter]

Dear all, I change the Tab Control local variable with property node: Value, and it works.

And I seldom use local variable except for Path or boolean value.

PS: If we want the numeric value change event occures, we usually use the value(signal) property instead of value.

Thanks.

Tom.

I would actually rather have changed the string value property to a local variable instead.

It is a noble attempt to avoid locals as much as possible, but using the value property instead is in fact fighting the devil with the beelzebub.

Rolf Kalbermatter

[MikaelH]

I like the property node since they have Error in/Out that makes the me in control of the flow.

But the property nodes are slow.

This code takes around 8 ms, but if you change it to the property node it takes 10 seconds.

That is because the control works in Synchronous mode.

You get the same time if you set the control to "Synchronous Display" but still uses a local variable.

So my conclusion is to always use the Property Node when updating a Tab control.

Cheers,

Mikael

[Rolf Kalbermatter]

I like the property node since they have Error in/Out that makes the me in control of the flow.

But the property nodes are slow.

This code takes around 8 ms, but if you change it to the property node it takes 10 seconds.

That is because the control works in Synchronous mode.

You get the same time if you set the control to "Synchronous Display" but still uses a local variable.

So my conclusion is to always use the Property Node when updating a Tab control.

Somehow I can't follow you. First you say that the property node is terribly slow, although the reasoning for that is only partly right. Yes it operates in synchronous mode so it will force an update of the control on each iteration before going to the next iteration, but there is also additional overhead because the property node (any VI server property node at that not just the value one) has to run in the UI thread so there are also always two context switches involved.

And then you say one should always use the property Node for a tab control. I always use a local for that and had not any problems so far. I think we had established that the problem here was the "parallel" execution of the string property node (and only for an element contained on the tab control) when updating the tab control through a local variable. So replacing the string property node with a local variable seems to me the better solution.

Rolf Kalbermatter

[MikaelH]

So replacing the string property node with a local variable seems to me the better solution.

Sure it's one solution, but assume that I use the local variable for the Tab Control and use a local variable for the string.

And then suddenly we need to update this code to also gray out the string control, so I change it to a property node to disable the control and at the same time I use the same property node to update the value of the string control.

But of cause I now know about this problem so I have to change the updating of the tab to a property node.

But I have 5 LV developers in my team and I can't do all updates myself so maybe the developer I assign this task to might not remember this.

Cheers,

Mikael