LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Synchronising scale changes between two sliders

I have anohter problem which feels trivial but upon trying to actually implement it appears anything but....

 

I have two sliders superimposed (One is for max-min range with fill, the other is for Target value and Current value with fill).  I need to keep both slider scales synchronised and I need to separate the functionality into two different sliders otherwise the fill options collide.  We have some buttons for autoscale, panning and so on.  These programmatic changes are easy to synchronise, just update both scales accordingly.

 

Problems occur when trying to synchronise manual editing of the scale limits (which I definitely still want to allow).  There is no "Scale Range Change" event like there is for Graphs.  The "Scale" reference from the Slider also allows no events to be registered.  Even the "Key Up" event of the slider does not work because at this point in time apparently the scale itself has not yet been updated.

 

I'm using LV 2012 SP1, so any new events added in later versions is of no use to me.

 

Polling is looking like the only valid option here.  Ugh.  Either that or a daemon which waits approx. 10ms (magic delay fairy!) and then "manually" synchronises the scales..... Smiley Mad

0 Kudos
Message 1 of 6
(3,064 Views)

Hi,

 

I don't fully understand why you have to separate the slides. My first thought was to have two sliders in one slide control and handle the fill options event based. That way you don't have to manage the scales. This is just a first idea, though and can certainly be done in a better way:

 Sliders.png



Remember Cunningham's Law
0 Kudos
Message 2 of 6
(3,050 Views)

I tend to agree with Peter. My limited experience with multiple sliders has been that you can use their values to determine which slider represents which limits and thus change their roles and properties accordingly.

 


@Intaris wrote:

Polling is looking like the only valid option here.  Ugh.  Either that or a daemon which waits approx. 10ms (magic delay fairy!) and then "manually" synchronises the scales..... Smiley Mad

Uh, 10 ms from what? Presumably you're still talking about polling, but just with a daemon? I tend to agree that if you can't just use the single slide then polling seems like a reasonable option. Another option is to replace the scale with some other control on which you can get a value change event, but I'm coming up blank on controls which would properly emulate a scale.


___________________
Try to take over the world!
0 Kudos
Message 3 of 6
(3,043 Views)

P.S.: It is generally not recommended to put several FP elements on top of each other as this slows down your program. I must have a demo of that somewhere round here....



Remember Cunningham's Law
0 Kudos
Message 4 of 6
(3,035 Views)

Yes, it might be possible to do this with a single slider.  It's probably the easiest method since polling is just evil.

 

The sliders in question already have 2 sliders each, I thought managing the relative positions (seeing how the diffedrent fill ranges could overlap) would be easier on separate controls, but alas no.  We also have strict references to the sliders elsewhere, so that might require further changes to the code.

 

A control with 4 sliders is a bit more complicated but less complicated than any other alternative I cant hink of.  A bit of juggling whenever the values change.....

0 Kudos
Message 5 of 6
(3,024 Views)

@PeterFoerster wrote:

P.S.: It is generally not recommended to put several FP elements on top of each other as this slows down your program. I must have a demo of that somewhere round here....


I know that but given the very limited ability to customise LV controls, sometimes it's still the best way.  Especially since redrawing a slider isn't exactly a taxing enterprise for the CPU.  A graph is different, but a slider is not too bad.

0 Kudos
Message 6 of 6
(3,020 Views)