08-06-2010 05:33 PM - edited 08-06-2010 05:36 PM
Hello everybody
I have a very simple question. Find attached a VI that generates a sequence of random numbers (501 elements) and feed this sequence to a XY graph. But I have some issues concerning the horizontal scrollbar. After running tue VI, change by yourself the maximum value of X to 300. Now, using the scrollbar, move the graph to the right or to the left by clicking over the red and yellow areas of the scrollbar (view attached picture). Nevertheless, if you move the graph by clicking on the blue buttons (left and right arrows at the scrollbar), after you reach the limit to the left (0) or to the right (500), if you continue clicking on the arrows the range will bet out of range (i.e: 220 to 520; 240 to 540 or -20 to 280; -40 to 260 and so on).
I want to prevent the code from doing that. Even if I use the left and right arrows on the scrollbar, I want to limit the range to the minimum of 0 and maximum of 500. What should I do?
Thanks
Dan07
Solved! Go to Solution.
08-06-2010 08:48 PM
To my knowledge, this is the only workaround: introduce your own horizontal scrollbar with coerced limits. Set it's min/max/increment range via property nodes based on what graph range you want to scroll. Create an event handler structure that watches for the Value Change of the scrollbar, and use the NewVal to feed the appropriate fields (Min/Max) XScale.Range property node.
The trick is to keep the scrollbar synchronized with the data in the graph. Ensure anytime the data changes, so do the limits of the scrollbar scale.
.
08-06-2010 08:56 PM
One alternative is to use the 'Scale Range Change' event and check for the limits. Coerce the limits as necessary. There will be a trick to this. The new limits will be newmax and newmin. If newmax>max.allowed then set newmax=max.allowed and newmin = max.alllowed - (newmax-newmin). This is so the range isn't changed. Not a perfect fix, but effective. A filter event here would be nice.
08-06-2010 09:00 PM
Darin.K... I think I may have tried that before, and the graph is prone to flickering??? Or maybe the scrollbar was jumpy?? I agree, a filter event would be good here, or a flag that says "don't scroll beyond data limits", or a reference to the scrollbar to set coercion properties, or using that reference and a filter event to prevent Value Change out of range....
08-06-2010 10:41 PM
Some strategic Panel Update Deferrals remove almost all of the flickering. If I remember correctly, I would defer updates in the Mouse Down? event and stop deferring in the timeout case. I use a shift register to vary the timeout.
Initial timeout = -1. For Mouse Down? case, set timeout to say 100 msec. For Scale Change Case set timeout to 0. For the timeout case, set timeout to -1.
When the mouse is pressed, updates are deferred. If the event was a scale change (ie. scrollbar or drag), undo the damage before updating the panel. Otherwise, start updating again after a non-noticable pause.
If I were at work I would have the example in hand.
Or I could kick the inlaws out of the house and reclaim my office with my home LV machine.