From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

"Limit maximum instances of this event in event queue" not working within XControl Facade

I'm trying to use "Limit maximum instances of a mouse wheel event in event queue" inside an XControl Facade VI. In most case, the "Limit maximum instances" option works just fine. But when I use it within a Facade, I noticed that when the event case is running, and more of the same events are generated, they will be enqueued after the case finishes one after another, rather than being enqueued and flushed while running.

 

To be more specific, consider the following VI. I have already checked "Limit maximum instances of this event in event queue" option and set the "Instance" to 1.

sshot-49.png

When I click the Boolean 5 times within 2 sec, I'm expecting this event case to run only twice. All events between the first and last should be enqueued and flushed.

 

But what I got from Event Inspector Window is the following.

sshot-48.png

The Timeout event seems to prevent the Value Change event from enqueuing.

 

Is there a way of discard some events within Facade VI, like what the "Limit maximum instances of this event in event queue" option supposed to do?

0 Kudos
Message 1 of 5
(3,078 Views)

From experience the Limit maximum instances of this event in event queue has no effect in the Facade VI. LabVIEW seems to internally buffer the events and feeds them to the XControl regardless of this setting.

 

That said, you can limit the number of Data Change events which are received by the XControl. To do this, edit the .xctl file with a text editor and add in the bolded line below:

 

<Property Name="NI.Lib.Version" Type="Str">1.0.0.0</Property>
<Property Name="NI.XClass.Flags" Type="Int">0</Property>
<Property Name="NI.XCtl.OptimizeDataUpdate" Type="Bool">true</Property>
<Property Name="NI.XItem.DeclaredLeakProof" Type="Bool">false</Property>

I've used this trick extensively for XControls bound to tag variables so they update in a timely fashion. I'm unsure if this will have any effect on other events, but it might be worth a shot.

 

Source: https://lavag.org/topic/15680-no-update-on-x-control-value-change/




Certified LabVIEW Architect
Unless otherwise stated, all code snippets and examples provided
by me are "as is", and are free to use and modify without attribution.
0 Kudos
Message 2 of 5
(2,990 Views)

Thank you for the advice. I tried but it seems not working for my case.

 

I've solved this by creating a helper VI that performs all the slow operations. The Facade merely sends those events to the helper VI and the latter will make decisions on whether to discard or combine some of those operations.

0 Kudos
Message 3 of 5
(2,900 Views)

(Sorry, posting by phone, cannot test)

 

I don't think this should be handled in the x-control, but in the caller. What happens if you limit the x-control interaction to one in the event structure of the program containing the x-control?

0 Kudos
Message 4 of 5
(2,889 Views)

Sorry for the late response.

 

Say I have a control on the Facade VI FP and I register some event associated with that control, say Mouse Down. The event is registered and handled within the Facade VI. So there will not be an event case associated with that event in the caller, and I think I will not be able to register for such event from the caller either. I guess every time I click that control from the caller of the x-control, that event will get fired. Am I right about this? Is it possible to "block" the UI interaction here? 

0 Kudos
Message 5 of 5
(2,830 Views)