Slider bug in 4.18.0?

[wired]

I believe there is a bug in the slider widget in 4.18.0. I am using a slider to quickly adjust a parameter, but my incremental values are so small that I cannot easily position the slider on each unique value using the touchscreen, i.e. the button may be centered on the same pixel for two consecutive slider values. For this reason, I have created increment and decrement buttons. One button increments by a larger amount (1mA), and one by the adjustment resolution of the parameter (0.05 mA). In the interactions, I calculate the value to display in the text area.In this example, I go from 0.05 to 10.00 mA in 0.05 mA increments. So, the range of the slider is from 1 to 200, and to calculate the text value to be displayed, I divide by 20.0. What I discovered is that when using the 'increment by 1' button, when I start at the low end of the slider there are 4 places where the incrementing stops, and I cannot programmatically increase the slider, even though I am adding 1 to its value each time the button is pressed. Once I manually scroll past the last stopping point (which is around 1.2mA), I can use the increment button all the way up to the maximum. The same problem occurs in reverse when decrementing from the high end of the slider. The problem points seem to be symmetric with respect to the slider. I suspected it may have something to do with consecutive slider values resolving to the same slider button position (graphically), so I tried increasing the maximum slider value to 2000 to test the theory. Now I can no longer use my 'increment/decrement by 1' buttons anywhere on the slider. I suspect the code is doing something odd if a change in the slider value would not result in movement of the slider button when redrawn. This is not desired behaviour IMO, because if I increment the slider value by 1, it should be incremented by 1 regardless of how the graphics are drawn. I am using the getValue, getMaxValue, getMinValue, and setValue functions in the buttons' interaction code.

I really want to use the slider on the touchscreen to get in the ballpark quickly, and then use the buttons to get to the exact value. With the way it is behaving, I will not be able to use the slider at all.

[MM..1]

Maybe you need understand pixels to range slider ratio. When you use ilegal size your slider canot result all values.

Then for example for range 1 to 200 size for your slider need be 200 px width or 400 or 600 usw.

[wired]

I completely understand the pixel to slider range ratio. The Designer does not restrict your slider range to the number of pixels in the slider.

I do not expect the slider to always move on-screen when I change its value using the increment button if my range is greater than the slider's pixel width. I do, however, expect that when I do the following, my slider value should be incremented by one, so that when I use the slider value to determine the number to display, I get a correct number even if the slider didn't move on the screen when its value was programmatically incremented:

void ScreenAdjustAmpltudeView::IncByOnePressed()
{
	int value = sliderAdjustAmp.getValue() + 1;
	if (value > sliderAdjustAmp.getMaxValue()) value = sliderAdjustAmp.getMaxValue(); 
        sliderAdjustAmp.setValue(value);
}

This is not happening. The slider implementation should allow the slider value to be set to any value within the defined range, and then calculate the correct position onscreen to display the slider button. I am guessing that when I do a setValue, the implementation of the widget is moving the slider position to the closest position given the pixel width of the slider, and then recalculating the value based on where it was put. It should not do that unless the slider was actually moved by the user. The value of the slider should only be automatically changed if the user slides the slider. In other words, I should be able to set a slider range of 500, even if my pixel width is 100, and with the slider at the minimum value, click my increment button 500 times and end up at the maximum slider position. This is what I would consider proper behavior of the slider widget, given that you are able to specify a range larger than the pixel width.

[wired]

To make this whole topic even more simple, let me just state the following:

If I do a programmatic slider.setValue(value), I should always get the same value back when I do a subsequent slider.getValue() if the slider has not been touched. I do not, therefore this is a bug.

[MM..1]

No read docu for Slider about round. And touchGFX is environment for touch operation primary, then slider with range 500 but width 100 can set only every 5th value.

For your situation is better combine Slider and TextArea. Draged sliding calculate values and show it int TextArea. Clicks on arows corect values to precise point.

Result value isnt slider get , but textarea showed variable...

But yes ideal is as you write stored value in slider properties

Slider is class that can be extend or ...

See Middlewares\ST\touchgfx\framework\source\touchgfx\containers\Slider.cpp 

[wired]

I appreciate your comments and the suggestion, but I would really like the slider to work properly. Given no other stimulus, a setValue followed by a getValue should always return the value that was set. I looked at the slider code, and it appears to be a fairly simple matter to have it behave that way, without affecting backward compatibility. The way it functions now somewhat defeats the purpose of the Values properties in the Designer. I have no problem with the slider's currentValue being calculated based on the pixel resolution, but only when the user clicks, moves, or releases the slider button.

The slider itself is meaningless without values being attached to it, i.e. it is purely an indicator of relative position within a range. It is the actual value that is important, and that value should be able to be manipulated however the developer intends. If the slider worked as I described, its utility would be vastly improved IMO, and it could be used in many different types of GUI implementations, such as the one I described above. I really don't see a need to limit it the way it has been limited - by converting a value to a position, and then back to a value, which is what causes the problem. The setValue function can move the indicator position without updating the currentValue to one calculated from the new position. Simply calculate the new position for moving the indicator, but set the new currentValue to the exact value that was passed to setValue().

[JVALL.1]

I've been trying to make something similar for fine tuning the value of a slider, but in 4.20 the slider still has the same behavior and doesn't seem possible.

Did you managed to make the slider behave like you wanted? If so, what approach did you follow?

[wired · Accepted solution]

I haven't really dealt with the issue any more. I did send it to ST under tech support (case 0045125) when I started this post, and my tech support person finally agreed that was I said was correct, and that it could and should be improved and implemented as I proposed, and that he would bring up the issue with the firmware team for consideration in a future release. I wouldn't hold my breath.

I did not implement a workaround yet, just moved on to other things. I'll deal with it when I need to, but have bigger fish to fry.