We use cookies to give you the best experience on our website. If you continue to browse, then you agree to our privacy policy and cookie policy. Image for the cookie policy date
  1. Home
  2. Forum
  3. Xamarin.Forms
  4. Unexpected RangeSlider behaviour

Unexpected RangeSlider behaviour

Good day,

I am using the SFRangeSlider control in a MVVM environment using Prism/Unity.

The goal is to use two RangeSliders in a ContentPage. The first control allows the user to select a single value, the second control allows the user to modify the range of values shown by the first slider by adjusting the RangeStart and RangeStop properties of the second control. Code behind updates the first control's Minimum and Maximum values with the second controls RangeStart and RangeEnd values when the DragCompleted event is triggered.  A arbitrary Button control is used to make the two controls visible/invisible in the ContentPage

Scenario1 - works as expected:
The control values are initialised by the ViewModel page constructor and the RangeSliders are visible from the start. Adjusting the RangeStart and RangeEnd values in the second control changes the Minimum or Maximum values of the first control. After Intialise the first control's Value is set correctly.

Scenario2 - does not work as expected:
In this scenario the ViewModel constructor does not initialise the two control's values and the controls are not visible directly after Initialise.
The user can make the controls visible via the Button control that sets the IsVisible property in the ViewModel making the two control visible.
In this scenario the RangeStart/RangeEnd values of the second control as well as the Value of the first control seems not to be updated correctly.

The two scenarios can be replicated by setting the RSISVisible flag to either true or false in line 118 of Page1ViewModel.cs.

Question1:
Please provide some insight into why  in scenario 2 the second controls RangeStart and RangeEnd values are not initialised correctly.

Question2:
Same as Q1, but applicable to the first control's Value property not being initialised correctly.

Question3:
What would be the correct approach to implement the DragCompleted event in a MVVM scenario. (Maybe using PRISM EventToCommand mechanism)?

I include a sample project used to test the scenarios. Kindly focus on Page1.xml, Page1.xml.cs and Page1ViewModel.cs that contain the relevant code.

Thank you in advance for having a look into my problem.

Warm regards







Attachment: Sample1a_bfa0fa72.zip

4 Replies
MK Muneesh Kumar G Syncfusion Team July 2, 2019 10:23 AM UTC

Hi Lan, 
 
Greeting from Syncfusion. 
 
We have analyzed your queries, please find the response below.  
 
Question1: Please provide some insight into why  in scenario 2 the second controls RangeStart and RangeEnd values are not initialised correctly. 
 
Question2: Same as Q1, but applicable to the first control's Value property not being initialised correctly. 
 
In both scenarios (Control values are initialized by the ViewModel page constructor & ViewModel constructor does not initialize the two control's values) the control values are properly updated based on the values provided in sample. We have attached a video. 
 
 
Since we are not aware of your exact application scenario, could you please share a video link to replicate this issue and let us know the device details and API version. This will be helpful for us to investigate further and provide you a better solution at the earliest.  
 
Question3: What would be the correct approach to implement the DragCompleted event in a MVVM scenario. (Maybe using PRISM EventToCommand mechanism)? 
 
We have modified your sample based on MVVM scenario using PRISM EventToCommand and get the sample from following link. 
 
 
Regards,
Muneesh Kumar G. 


IA Ian July 2, 2019 03:26 PM UTC

Good day,

Thank you for the feedback:

Q3. The MVVM sample works fine thank you.

Q1&2 : I added a 55 sec video of my application with the following key points:

time = 00:00:04
When the ViewModel Constructor initialises the control properties through the bindings, the expected results are as shown.
Rangeslider2 Min=10, Max=73, RangeStart=31 and RangeEnd=52.
Rangslider1 Min = 31 and Max = 51 with Value correct.

time = 00:00:23
IsVisible is toggled that hides and unhides the controls.

time = 00:00:24
The togglebutton command handler initialises the rangeslider properties.
Rangslider2 Min=105, Max=735 is good.
RangSlider2  RangeStart=105 and RangeEnd=735 is not as expected - should be 315 and 525 each.
RangeSlider1 Min and Max are correct.
RangeSlider1 Value = 525 is wrong and should be at halfway point.

I hope this clarifies the unexpected behaviour.

Warm regards

Ian


Attachment: range_slider_operation_175ce29a.zip

MK Muneesh Kumar G Syncfusion Team July 5, 2019 12:46 PM UTC

Hi Lan,  
 
Thanks for your update. We were able to reproduce the issue “Unexpected RangeSlider behaviour” and we confirm this as a bug and logged a defect report. You can keep track of the bug from the feedback portal below. 
   
   
The fix for the reported issue will be available on 12th July ,2019.  
  
If you have any more specification/precise replication procedure or a scenario to be tested, you can add it as a comment in the portal. 
 
Regards, 
Muneesh Kumar G.  
 


MK Muneesh Kumar G Syncfusion Team July 12, 2019 01:29 PM UTC

Hi Lan, 
 
Please find the patch setup from the below location.   
 
 
or   
   
Please find the patch assemblies from the below location.   
 
 
or  
 
Please find the NuGet from the below location.   
 
 
 
Assembly Version: v17.2.0.34 
   
Disclaimer:    
  
Please note that we have created this patch for the version17.2.0.34 specifically to resolve the issue reported in this incident.  
  
We request before replacing the NuGet, please follow the below steps to clear the NuGet cache,  
  
For Windows  
  
Follow the below link to clear cache,  
  
For Mac  
  
• ~/.local/share/NuGet/Cache  
  
• ~/.nuget/package  
 
Also we have attached the assemblies for this fix  in 17.1.0.53 version from below link. 
 
 
Assembly Version: v17.1.0.53 
 
The fix for this issue will be included in our Volume 2 SP1 release. 
 
Regards, 
Muneesh Kumar G. 


Loader.
Up arrow icon