QControl Enthusiasts

cancel
Showing results for 
Search instead for 
Did you mean: 

Help. New to QControls - I have a race condition

Solved!
Go to solution

I'm new and inexperienced with QControls, so I'm not sure how to best handle my problem. I created a new QControl string type that checks the text for "validity" and sets formatting properties of the contained text. So my Event Handler is registered to "Key Press" and executes a simple subVI that formats the string and sets a State boolean. But in certain circumstances the QControl can change the string value directly, which it does by writing to a Value(Signalling) property node. To ensure the formatting is applied again the event handler is also registered for "Value Change". Both events run the same subvi.

 

Now, my race condition is this: In my calling VI, I also register for Value Change on the string control, and read the "valid?" boolean from the QControl state data, but it often gets stale data. This is because the two Events Handlers are triggering off the same Value Change, and I need them to occur in order (QControl first to set the state data, then the caller event structure). Not possible. So I believe there must be a better way to construct the QControl so that this issue doesn't occur.

 

I thought about using a dedicated user event from the QControl, such that the caller isn't triggering off the Value Change but instead when the QControl commands it, allowing sequential timing. But that feels like overkill. 

 

Alternatively, I can make sure the process that sets the string text also sets the properies before Val(Sgnl) is written. But this also feels like a hack.

 

Any advice?

Thoric (CLA, CLED, CTD and LabVIEW Champion)


0 Kudos
Message 1 of 4
(141 Views)
Solution
Accepted by topic author TheQ

Having two event structures registered for the same dynamic/static event is the same as having two registered for the same User Event; there is no way to guarantee which will execute first. The only way to secure the order operation is to have one event cause the second.

 

So, like you said, the only way to ensure your order is to have a User Event that your calling VI registers for and your QControl fires it when the "Value Change" event fires after the value change code is finished executing. I don't think that is overkill, it is just ensuring execution order via a messaging scheme (in this case a User Event).

 

Your alternative approach might be valid too, I don't know what properties need to be set before the Value (Signaling).

 

Personal opinion, I try to avoid using the Value (Signaling) property node because it confuses those reading the code if there is another way to apply the formatting. The Value (Signaling) property makes it difficult to know where that event is being fired to someone picking up your code for the first time. However, sometimes, that is the best way to do it.

Quentin "Q" Alldredge

Chief LabVIEW Architect, Testeract | Owner, Q Software Innovations, LLC (QSI)
Director, GCentral | Admin, LabVIEW Wiki | Creator, The QControl Toolkit
Certified LabVIEW Architect | LabVIEW Champion | NI Alliance Partner



Message 2 of 4
(109 Views)

Thanks Quentin,

 

I added a custom user event which is generated after the qctrl has finished, that seems to work well. Not as much effort as I had worried it might be, so I'm happy. 

 

Liking Q Controls, thank you for publishing your work 👍

Thoric (CLA, CLED, CTD and LabVIEW Champion)


Message 3 of 4
(93 Views)

I'm glad it worked for you! Let me know if you have any other questions and, if you can, consider sharing your QControl in the community contribution list or through VIPM.

Quentin "Q" Alldredge

Chief LabVIEW Architect, Testeract | Owner, Q Software Innovations, LLC (QSI)
Director, GCentral | Admin, LabVIEW Wiki | Creator, The QControl Toolkit
Certified LabVIEW Architect | LabVIEW Champion | NI Alliance Partner



0 Kudos
Message 4 of 4
(86 Views)