XControl misses Property calls

[Wirer]

Hi all!

So many thanks for everyone for nice ideas and examples! And sorry about the delay on my response: I was sick for few days (not only because of Xcontrols  ).

According to suggested solutions, it seems that the 'bug' or 'race condition' dealing with xcontrol property calls can be handled in other ways. Queues and semaphores are useful many times and especially in this case.

Until the build-in mechanism stays unsolved, proposed mechanisms can be used and have to be used .

Regards,

Wirer

[Jarrod_S.]

This was reported to R&D (# 42I8HFV2) for further investigation. Thanks for the feedback!

[TCPlomp]

In order to have seperate xcontrols I have used the following code to create a unique semaphore.



Ton

Message Edited by TonP on 01-19-2007 10:00 AM

[minnellac]

Okay, I'm working on my first graph control, and I believe I've run into this issue. I quick glance at the 8.2.1 bug fixes doesn't seem to indicate that this issue has been resolved. Is there any consensus on how to work around the problem? Both queues and semaphores were mentioned here.

Is this a reasonable approach:
initialize a semaphore with a unique id when the control is initialized (destroy in the uninit case). Store the id in the display state cluster, and have each property vi acquire the semaphore. Release the semaphore in the display state change case of the facade vi. In theory, this would force properties (and methods) to wait for the preceding property to run before attempting to change something else in the display state cluster.

Is it enough to release the semaphore in the display state change case?

Thanks for any assistance.
Chris

[Jarrod_S.]

This hasn't been fixed yet. There isn't a consensus on which of the workarounds is the preferred one, because they have different functionality.

If you want the property node call for the XControl not to finish executing until you are sure that the message has been registered by the XControl, then you will want either the semaphore or perhaps a single-element queue. If you just want to post a message to the XControl that doesn't necessarily need to get handled immediately, then an unbounded queue will do fine for you.

Your description of using the semaphore appears to be mostly acceptable, but I would warn of the following race condition:

Suppose one property node acquires the semaphore and starts executing. Before it can finish the Display State Change event case executes due to some reason other than the property node (property nodes aren't the only reason this case executes.). That releases the semaphore, and another property node that was waiting starts to execute while the first is still running. This might seem unlikely, and even in this case I don't think there'd be any harm since the loss of data problem involves three concurrent property node calls, not two.

But for your sanity I would propose sending a message from the property node to the Display State Change event case of your XControl indicating the origin of the event. Then only release the semaphore after processing an event from a property node.

[Matt_W1]

Has there been any updates on this problem, I've run into worse (but I believe related problem) with an xcontrol that I've written. Basically in my case the Display State Change event isn't fired after a property node is called and the new state data is completely lost. I've tried using semaphores but since the facade never sees the event it can't release the semaphore and therefore locks up. I haven't been able to produce a simplified version of the problem (or I would attach it here), so it maybe caused some weird combination of things (my programs is fairly complicated). But with run highlight execution on the calling vi's block diagram and facade block diagrams (I'm using two instances of the same xcontrol), I can consistently watch the properties being called in one vi, but the related events never occurring in the facade vis.

Matt W

[minnellac]

I played around with a semaphore approach for a while and gave up. I switched to an approach where I wrote an action engine for property changes, where the property change was accomplished by, in a loop, writing and reading the property until I could detect a change. I still experienced problems with this, so I finally gave up and just changed my control property to the entire Display State cluster. This way, I can just call the property node once with everything I want to change (it seems like the problems come from multiple property node calls that run so quickly that some display state information is lost when some/most cases don't get executed in the xcontrol). This technique sort of works, but there is still a problem preventing the property node from executing before the xcontrol has had an opportunity to run the data change case. It matters in my case because I am trying to set plot names, and it doesn't work if there isn't data in the graph yet to support the number of plots. Data flow is broken, that is, you can not guarantee the order of execution by controlling the order that your elements (property nodes, terminals) are executed.

Two things would probably make this better for me: 1) a major overhaul of xControls to fix these race conditions, or 2) the abilty to inherit functionality from the elements of the xControl (I have a graph control in my xControl, I'd like to inherit the properties of the graph control so I don't have to add each one individually--and not have them work correctly anyway).

I've pretty much decided to scrap the xControl, and just transition all the code to the actual vi it's being used in. It will be messy, but at least I can guarantee that it will work correctly. I don't know if this helped you at all, but at least it documents my troubles.

As an aside, it appears that in 8.2.1 the problem still exists that an ActiveX container can't be hidden on a tab page when that page is not in front; at least, when that activeX container is part of an xControl.