Intercepting slide range change

[spaghetti_developer]

Hi All,

This is a simple question: how can I intercept when the user change scale of the range on a slide control on the FP? Does labview generete an event that can be handled?

Thank you in advance.

Regards.

[spaghetti_developer]

Troubleshoot it. I have simply intercepted the key down event, the mouse leave event and also the mouse down event. Inside those events I get the new range of the control from its property nodes scale.minimum and scale.maximum and check if they are different from saved values on the shift register of the event-loop. It works good.

[Aristos Queue]

Another variation that works for almost all similar situations is to have a separate loop that just polls every 100ms or so, comparing the last known value (in shift register) to the current value. If it detects a change in the value, then it fires a User Event. This allows your main event loop to not have to have the shift register logic inside of it, making it easier to add/remove the handling for additional scales or other run-time-changeable properties. Yes, it is a polling loop that is continuously running, but in the vast majority of VIs intended for the user to actually see, it has no human-noticeable impact on the responsiveness of the UI.

[asbo]

Another variation that works for almost all similar situations is to have a separate loop that just polls every 100ms or so, comparing the last known value (in shift register) to the current value. If it detects a change in the value, then it fires a User Event. This allows your main event loop to not have to have the shift register logic inside of it, making it easier to add/remove the handling for additional scales or other run-time-changeable properties. Yes, it is a polling loop that is continuously running, but in the vast majority of VIs intended for the user to actually see, it has no human-noticeable impact on the responsiveness of the UI.

If someone has a real aversion to the polling method, it might be just as well to make a parallel event loop, registering for the same events you would in your main loop.

[Aristos Queue]

If someone has a real aversion to the polling method, it might be just as well to make a parallel event loop, registering for the same events you would in your main loop.

The problem is that in this case, there are no events that directly represent the action for which the programmer wants to register. Registering for the mouse and keyboard events is a hack that has to be done very precisely, and it gets really tricky when there are multiple controls/labels/etc that need to be monitored. The polling loop addresses these concerns.

[asbo]

Registering for the mouse and keyboard events is a hack that has to be done very precisely, and it gets really tricky when there are multiple controls/labels/etc that need to be monitored. The polling loop addresses these concerns.

Very true. Your suggestion makes better sense now.

Has anyone written a framework to turn a polling VI into a User Event? I think it could be made generic enough to have some good use cases, though it would probably need to be class-based in order to use strict typing on the UEs. Could be fun to develop.

[Aristos Queue]

To the best of my knowledge, no, no one has made efforts in that direction.

[Darin]

At best, the Events are a bit like an occurrence, not a replacement for polling, just a good hint at what might be a good time to poll. The problem as AQ hints at, is that it can be tricky to catch all of the ways that a user can change the scale range. For example, what if I paste a new value, and then make another window active and then return to the FP. The new value is entered via this process without a key press or mouse click. Polling is a robust method to catch these changes. And since I started using LV long before the days of the Event Structure I will pass along a tip from the old days: a simple way to throttle the polling loop is to use the "Wait for Front Panel Activity" function with a long timeout (500 msec). Keeps it responsive when necessary, and out of your way when nothing is happening.

In many instances I do not display the Marker values for a slider, and I actually use separate controls to set the range. This makes it very easy to detect the value change.

[GregSands]

a simple way to throttle the polling loop is to use the "Wait for Front Panel Activity" function with a long timeout (500 msec)

How can I have never known about this function? Thank you!

[TG]

a simple way to throttle the polling loop is to use the "Wait for Front Panel Activity" function with a long timeout (500 msec)

How can I have never known about this function? Thank you!

ALso when you convert an event loop into a polling event loop you will find that no matter how big the delay is your event case will respond immediately

to your keypress or value change!

Possible Reason for not knowing this it is NI always say "don't use the timeout" as it defeats the purpose of events.. I don't agree with that statement entirely.

Having a timeout is a nice when you want to have a way to get control back when developing event handling code.

Once developed it can be removed easily.