I'm not sure how to describe this. I have a RadSlider that controls a dynamic range adjustment of an image. I've bound the slider selection values to a property named "DraSelection". As the user moves the max slider button and I get calls to DraSelection::set, I continually update the DRA of the image. This can be expensive computationally, but I need it to updates to happen immediately to the image so I have to set DeferredDraggingEnabled to "false".
As a result, sometimes the DRA processing just can't keep up with the user moving the slider. I would be OK with that (it will catch up when the user stops moving) but I've found that when this happens -- when we get into these laggy situations -- RadSlider starts sending me bizarre calls to DraSelection::set as if it's trying to "predict" where the slider is going to be rather than telling me where it actually is.
To illustrate, it happens like this:
1. Picture a range of, say, 0 to 100 for the slider
2. Min slider is at 0, Max is at 100
3. User grabs the max slider button and start moving the max down. 99, 98, etc
4. With each move, i get a DraSelection::set from Telerik.
5. I call some expensive function (call it "SetDra"). It is expensive enough to let the user move the slider many ticks before it returns
6. Eventually, the user has moved the max button quite a bit, say, down to... 75. without the SetDra() function having returned.
7. Now RadSlider suddenly gives me a DraSelection::set call and the max value is something ridiculously low, like... 40.
Note that at no point did the user ever actually move the slider to 40 or anywhere near it. But RadSlider gave me an update as if he did. So the slider jumped all the way to the left (40) while the mouse cursor was still sitting to the right at 75. It is as if RadSlider "predicted" it was going to be at 40 by the next time it could get something done so it just "faked" it.
Note also that the user still has the mouse button down. He hasn't even lifted it up at this point. He's just paused. So technically he is still dragging that slider. And if he then (after a delay) moves it just a tiny bit -- like from 75 to 76, then the max slider jumps all the way back from 40 to 76 and I get another DraSelection::set with a max of 76 again.
I can't have this behavior in a finished product but I need immediate processing. Is there any way to turn off this behavior without setting DeferredDraggingEnabled to "true"
I should note that I am using version 2012.3.1129.40 of Telerik. I am not permitted to update to a more recent version now but will as soon as I can. Sso if this is some sort of bug that has been fixed, is there any other workaround besides deferred dragging?.
Or perhaps I'm doing something wrong. Here's my XAML (minus some irrelevant properties)
<tk:RadSlider x:Name="DraSlider"
VerticalAlignment="Top"
HorizontalAlignment="Stretch"
Ticks="0"
Minimum="{Binding Path=DraRangeMin}"
Maximum="{Binding Path=DraRangeMax}"
Visibility="{Binding Path=Ready, Converter={StaticResource CvtBoolToVis}}"
IsEnabled="{Binding Path=CanUpdateDraSliders}"
Selection="{Binding Path=DraSelection, Mode=TwoWay}"
SelectionChanged="DraSlider_OnSelectionChanged"
StepAction="MoveRange"
IsSelectionRangeEnabled="True">
As a result, sometimes the DRA processing just can't keep up with the user moving the slider. I would be OK with that (it will catch up when the user stops moving) but I've found that when this happens -- when we get into these laggy situations -- RadSlider starts sending me bizarre calls to DraSelection::set as if it's trying to "predict" where the slider is going to be rather than telling me where it actually is.
To illustrate, it happens like this:
1. Picture a range of, say, 0 to 100 for the slider
2. Min slider is at 0, Max is at 100
3. User grabs the max slider button and start moving the max down. 99, 98, etc
4. With each move, i get a DraSelection::set from Telerik.
5. I call some expensive function (call it "SetDra"). It is expensive enough to let the user move the slider many ticks before it returns
6. Eventually, the user has moved the max button quite a bit, say, down to... 75. without the SetDra() function having returned.
7. Now RadSlider suddenly gives me a DraSelection::set call and the max value is something ridiculously low, like... 40.
Note that at no point did the user ever actually move the slider to 40 or anywhere near it. But RadSlider gave me an update as if he did. So the slider jumped all the way to the left (40) while the mouse cursor was still sitting to the right at 75. It is as if RadSlider "predicted" it was going to be at 40 by the next time it could get something done so it just "faked" it.
Note also that the user still has the mouse button down. He hasn't even lifted it up at this point. He's just paused. So technically he is still dragging that slider. And if he then (after a delay) moves it just a tiny bit -- like from 75 to 76, then the max slider jumps all the way back from 40 to 76 and I get another DraSelection::set with a max of 76 again.
I can't have this behavior in a finished product but I need immediate processing. Is there any way to turn off this behavior without setting DeferredDraggingEnabled to "true"
I should note that I am using version 2012.3.1129.40 of Telerik. I am not permitted to update to a more recent version now but will as soon as I can. Sso if this is some sort of bug that has been fixed, is there any other workaround besides deferred dragging?.
Or perhaps I'm doing something wrong. Here's my XAML (minus some irrelevant properties)
<tk:RadSlider x:Name="DraSlider"
VerticalAlignment="Top"
HorizontalAlignment="Stretch"
Ticks="0"
Minimum="{Binding Path=DraRangeMin}"
Maximum="{Binding Path=DraRangeMax}"
Visibility="{Binding Path=Ready, Converter={StaticResource CvtBoolToVis}}"
IsEnabled="{Binding Path=CanUpdateDraSliders}"
Selection="{Binding Path=DraSelection, Mode=TwoWay}"
SelectionChanged="DraSlider_OnSelectionChanged"
StepAction="MoveRange"
IsSelectionRangeEnabled="True">
3 Answers, 1 is accepted
0
Hello ,
Thank you for the detailed description of your scenario.
I have tried to reproduce the behavior that you have described, but with no success. That is why I would like yo ask you a few questions:
- you mentioned that "Min slider is at 0, Max is at 100". Do you mean that the Selection.Start =0 and Selection.End =100 or you mean the Minimum and Maximum properties of the RadSlider.
- "User grabs the max slider button and start moving the max down" the same question applies does the user moves the SelectionEnd thumb or you are moving the Maximum property of the RadSlider.
- do you execute the expensive operation you mentioned in the PropertyChanged callback of the RadSlider or in the binding inside your view model?
- do you run the expensive operation in a different thread or you remain in the UI one? If you execute the operation in the UI thread the UI should freeze until the operation completes and then return the control over the slider.
Also if possible could you please attach us a sample project reproducing the behavior.
Looking forward to hearing from you.
Kind regards,
Kiril Vandov
Telerik
Thank you for the detailed description of your scenario.
I have tried to reproduce the behavior that you have described, but with no success. That is why I would like yo ask you a few questions:
- you mentioned that "Min slider is at 0, Max is at 100". Do you mean that the Selection.Start =0 and Selection.End =100 or you mean the Minimum and Maximum properties of the RadSlider.
- "User grabs the max slider button and start moving the max down" the same question applies does the user moves the SelectionEnd thumb or you are moving the Maximum property of the RadSlider.
- do you execute the expensive operation you mentioned in the PropertyChanged callback of the RadSlider or in the binding inside your view model?
- do you run the expensive operation in a different thread or you remain in the UI one? If you execute the operation in the UI thread the UI should freeze until the operation completes and then return the control over the slider.
Also if possible could you please attach us a sample project reproducing the behavior.
Looking forward to hearing from you.
Kind regards,
Kiril Vandov
Telerik
Check out Telerik Analytics, the service which allows developers to discover app usage patterns, analyze user data, log exceptions, solve problems and profile application performance at run time. Watch the videos and start improving your app based on facts, not hunches.
0
Joseph
Top achievements
Rank 1
Rank 1
answered on 27 Aug 2014, 07:21 PM
Hi Kiril.
When I say "Min slider is at 0, Max is at 100", I mean that Selection.Start = 0 and Selection.End = 100. The minimum and maximum properties are unimportant (except of course that they are larger than the 0 to 100 range).
When the user "grabs the max slider" I mean he's moving the right thumb button to the left
I do execute the expensive operation in the in the DraSelection::set() function, called by the Telerik code in response to the moving of the thumb button. (Currently my event handler (DraSlider_OnSelectionChanged) does nothing. I should not have put that in there. It's only in there currently in my attempts to debug this problem. But it happens even if that event handler does not exist)
The expensive operation happens in the same, user-interface thread that handles the DraSelection::set() function. There is no multithreading involved. (The operation involves some expensive mathematical calculations on image data for a dynamic range adjustment).
Hope this helps. Not sure what I can do to stop this behavior
When I say "Min slider is at 0, Max is at 100", I mean that Selection.Start = 0 and Selection.End = 100. The minimum and maximum properties are unimportant (except of course that they are larger than the 0 to 100 range).
When the user "grabs the max slider" I mean he's moving the right thumb button to the left
I do execute the expensive operation in the in the DraSelection::set() function, called by the Telerik code in response to the moving of the thumb button. (Currently my event handler (DraSlider_OnSelectionChanged) does nothing. I should not have put that in there. It's only in there currently in my attempts to debug this problem. But it happens even if that event handler does not exist)
The expensive operation happens in the same, user-interface thread that handles the DraSelection::set() function. There is no multithreading involved. (The operation involves some expensive mathematical calculations on image data for a dynamic range adjustment).
Hope this helps. Not sure what I can do to stop this behavior
0
H ,
I was not able to reproduce the behavior on our side even using the updated information using the 2012.3.1129.40 binaries. I have tried to reproduce the issue even on a slower machine (2GB of RAM) but the slider continued to report correct values. That is why I would like to ask you to take a look at the attached project and modify it in order to reproduce the issue on our side.
Kind regards,
Kiril Vandov
Telerik
I was not able to reproduce the behavior on our side even using the updated information using the 2012.3.1129.40 binaries. I have tried to reproduce the issue even on a slower machine (2GB of RAM) but the slider continued to report correct values. That is why I would like to ask you to take a look at the attached project and modify it in order to reproduce the issue on our side.
Kind regards,
Kiril Vandov
Telerik
Check out Telerik Analytics, the service which allows developers to discover app usage patterns, analyze user data, log exceptions, solve problems and profile application performance at run time. Watch the videos and start improving your app based on facts, not hunches.