Slider step, value does not agree with setting when sliding vs. using the arrow

[Nasser M. Abbasi]

I setup this slider so that when using the arrow (the minor step)
it will move by 1 and when clicking inside the slider (the
major step) it will move by 10.

All is ok. But what about when actually sliding the slider
itself? In this case, in the callback, I see the value
returned is not in steps of 1 as I expected, but in
fractions.

If you run this, and look at the console, you'll see it
print the current value. When using the arrows, all is
ok, but when sliding it by holding the inside stick
and sliding it with the mouse, now the steps are no
longer using the minor nor the major steps.

------------------------------------
foo=@(hObject,eventdata) disp(get(hObject,'Value'))

f=figure('Units','normalized','position',[.3 .3 .2 .2]);
h5 = uicontrol('Units','normalized','style',...
'slider','position',[.3 .3 .5 .2],'parent',f,...
'callback',foo,'Min',0,...
'Max',100,'Value',10,...
'SliderStep',[1/100 10/100]);
-------------------------------

Is there an option to control those steps as well? I thought
the minor step was what controlled those also?

Using 2012a

thanks,
--Nasser

[Nasser M. Abbasi]

Oh, and before someone replies saying that I can round
the numbers as I want, yes, I know I can do this, but
my question is why does the slider does not
move by the minor/major steps as expected.

[dpb]

On 3/1/2013 3:50 PM, Nasser M. Abbasi wrote:
> Oh, and before someone replies saying that I can round
> the numbers as I want, yes, I know I can do this, but
> my question is why does the slider does not
> move by the minor/major steps as expected.

...

Nothing in documentation indicates that is expected for other than the
movement in the arrow/channel portion of the slider control. When you
position the slider directly, the actual position is returned from
nearest pixel translated to range. This is Windows behavior and afaik
there's no OS support to control the actual slider position to the arrow
minor/major discretization steps.

IOW, it is the way it is...

--

[Nasser M. Abbasi]

I use rounding now to fix it. So it is not a big deal. But
this behavior makes no sense. A user does not care about
pixel images and such. The semantics of the behavior of
slider should be that it steps by only the minor or major
steps as instructed.

Just because Matlab can't do it, does not mean it is
not possible. Matlab could have very easily did the
rounding internally, just like a user does, so that it
keeps the step size to be the minor step size. (it
has all the information it needs to do this).

I use Mathematica all the time for doing the same thing, and
in Mathematica I can make a slider telling it the steps to move by,
and it always returns values by those increments, regardless
of how small or large they are. Here is an example
(Mathematica uses the third argument for step size, Matlab
uses the second argument). Here the step size is 0.001.

Note that there is only one step size for Mathematica slider.

-------------------
v = 0;
Row[{Slider[Dynamic[v], {0, 1, 0.001}], Dynamic[v]}]
-------------------

Screen shot:

http://12000.org/tmp/030113/slider.png

--Nasser

[dpb]

On 3/1/2013 5:06 PM, Nasser M. Abbasi wrote:
...

> Just because Matlab can't do it, does not mean it is
> not possible. Matlab could have very easily did the
> rounding internally, just like a user does, so that it
> keeps the step size to be the minor step size. (it
> has all the information it needs to do this).
>
> I use Mathematica all the time for doing the same thing, and
> in Mathematica I can make a slider telling it the steps to move by,
> and it always returns values by those increments, regardless

> of how small or large they are....

Didn't said it can't be done by the app; only that the OS API doesn't
support it directly at that level (at least in the level of the SDK I
have installed--I didn't look at more recent documentation). Matlab
mirrors the API interface.

--

[Nasser M. Abbasi]

I do not know anything about Matlab SDK and such.
My point is that, Matlab uicontrol sits in the middle
of the user and the OS. Hence this rounding/fixing up
can be done by the UIcontrol itself even if the OS API
does not support it.

user --> UIcontrol Slider ---> OS call

(I thought Matlab use Java internally for the GUI?)

Matlab has control of what code goes into the UIcontrol.
Hence it can adjust for shortcoming of the OS call if
the OS call to native slider calls do not support those
increments. Again, the UIcontrol slider has all the information
it needs to do the rounding such that it keeps the
increments as specified by the minor step values.

I wonder how other GUI handles this, like Java swing, C# UISlider
and such. They must have the same issue.

--Nasser

[dpb]

On 3/1/2013 6:46 PM, Nasser M. Abbasi wrote:
> On 3/1/2013 6:26 PM, dpb wrote:
>> On 3/1/2013 5:06 PM, Nasser M. Abbasi wrote:
>>
>
>> Didn't said it can't be done by the app; only that the OS API doesn't
>> support it directly at that level (at least in the level of the SDK I
>> have installed--I didn't look at more recent documentation). Matlab
>> mirrors the API interface.
>>
>
> I do not know anything about Matlab SDK and such.
> My point is that, Matlab uicontrol sits in the middle
> of the user and the OS. Hence this rounding/fixing up
> can be done by the UIcontrol itself even if the OS API
> does not support it.
>

...

Well, yes, that's what I just said--that it (ML) _could_ but it rather
simply reflects the behavior of the OS control (at least on Windows).

If you think it's important enough, file an enhancement request w/ TMW.

--

[Doug Schwarz]

In my opinion it would be a detriment request.

Nasser, you seem so certain that the slider operation should be the way
you want, but in my opinion it is correct now with three possible
increments. Think of it this way: the way it is now you can get what
you want, but if the change you want is made, it will be impossible to
have a smaller increment than the minor step. In other words, the
slider will have *less* functionality than it does now.

--
Doug Schwarz
dmschwarz&ieee,org
Make obvious changes to get real email address.

[Nasser M. Abbasi]

On 3/2/2013 3:18 PM, Doug Schwarz wrote:

> Think of it this way: the way it is now you can get what
> you want,

No. The way it is now is NOT what I want. That is the point.

I wanted it to move by the granularity I specified. That
is what the minor/major ticks are supposed to be for.

What is the point of going into all this pain to specify
the exact steps the slider should move by, if all this will
be thrown out the minute the user touches the slider and move
it directly using the mouse?

>but if the change you want is made, it will be impossible to
> have a smaller increment than the minor step.

That is what design stage is for.

At the design stage, you decide the minimum granularity you want
for your application to process as input and make the slider to
change by these increments.

>In other words, the
> slider will have *less* functionality than it does now.

No, it will then have the EXACT same functionality I specified.
it will be less random.

But a simple solution can exist: Have an option in the API to this
UIcontrol to specify which way it should behave.

So those who want deterministic behavior can choose that, and those
who do not can choose that.

Currently the way it works is broken IMNSHO. It forces the
user who wants the slider to move only by certain minimum steps
to do rounding on their end, when this was what the minor/major
steps settings was supposed to do.

--Nasser

[dpb]

On 3/2/2013 3:18 PM, Doug Schwarz wrote:

> In article<kgrl49$av9$1...@speranza.aioe.org>, dpb<no...@non.net> wrote:
>> On 3/1/2013 6:46 PM, Nasser M. Abbasi wrote:

...

>>> ... Matlab uicontrol sits in the middle

>>> of the user and the OS. Hence this rounding/fixing up
>>> can be done by the UIcontrol itself even if the OS API
>>> does not support it.
>>>
>> ...
>>
>> Well, yes, that's what I just said--that it (ML) _could_ but it rather
>> simply reflects the behavior of the OS control (at least on Windows).
>>
>> If you think it's important enough, file an enhancement request w/ TMW.
>
>
> In my opinion it would be a detriment request.

I didn't suggest I thought he'd have much of an audience or likely get
TMW to adopt it... :)

> Nasser, you seem so certain that the slider operation should be the way
> you want, but in my opinion it is correct now with three possible
> increments. Think of it this way: the way it is now you can get what
> you want, but if the change you want is made, it will be impossible to
> have a smaller increment than the minor step. In other words, the
> slider will have *less* functionality than it does now.

Not to mention it would break the expected behavior users know from
other Windows apps where they can typically move the slider itself to
obtain yet more granularity than provided by the arrow/keyboard.

--

[Nasser M. Abbasi]

On 3/2/2013 4:30 PM, dpb wrote:

> Not to mention it would break the expected behavior users know from
> other Windows apps where they can typically move the slider itself to
> obtain yet more granularity than provided by the arrow/keyboard.
>

wow, That must be some really an amazing mouse/hand coordination
where one can use the mouse to slide a slider by just say 0.0001 amount.

How can this be possible? Can one actually control by hand the
slider values to change by such a amout? Is this like super lazer
type of mouse?

But to obtain exact values from Slider, another simple solution
(other than having an option as I said before) it to allow
a small pop-up window to use to enter in it a more exact value
whenneeded.

This is what Mathematica does. This way, if I want a more refined
value for the slider (within allowed min/max) than what the step
size is, I can simply click on the right side of the slider, this open
a small inputfield where I can enter a value, in much more precise
way than possible by moving the slider, then click again to close
it.

Screen shot:

http://12000.org/tmp/030213/slider.png


--Nasser

[dpb]

On 3/2/2013 5:18 PM, Nasser M. Abbasi wrote:
> On 3/2/2013 4:30 PM, dpb wrote:
>
>> Not to mention it would break the expected behavior users know from
>> other Windows apps where they can typically move the slider itself to
>> obtain yet more granularity than provided by the arrow/keyboard.
>>
>
> wow, That must be some really an amazing mouse/hand coordination
> where one can use the mouse to slide a slider by just say 0.0001 amount.
>
> How can this be possible? Can one actually control by hand the
> slider values to change by such a amout? Is this like super lazer
> type of mouse?

What the amount is all depends on the range specified; it's the pixel
resolution that's the controlling amount and that's fixed by the
hardware/display/etc., ...

> But to obtain exact values from Slider, another simple solution
> (other than having an option as I said before) it to allow
> a small pop-up window to use to enter in it a more exact value
> whenneeded.
>

> This is what Mathematica does....

So use Mathematica... :) --or code your own--you could create such
yourself if want.

--

[Nasser M. Abbasi]

But I do :) The UI and graphics in Mathematica are
much more advanced.

Mathworks has not done any work on its GUI for years. GUIDE
is the same as it was 6-7 years ago. Nothing changes from
one Matlab version to another in terms of graphics. same old
UI controls. No updates. Nothing new.

--Nasser

[Doug Schwarz]

In article <kgtsph$3sf$1...@speranza.aioe.org>,

"Nasser M. Abbasi" <n...@12000.org> wrote:

> On 3/2/2013 3:18 PM, Doug Schwarz wrote:
>
> > Think of it this way: the way it is now you can get what
> > you want,
>
> No. The way it is now is NOT what I want. That is the point.

You misunderstand me and I should be more clear. I realize the way it
works now is not *exactly* what you want or else why would you have
written your complaint? But you can get what you want simply by
rounding the slider value in the callback function. You want two levels
of granularity and you can have them.

I want three levels of granularity: major step, minor step, and whatever
you get by moving the slider by one pixel. If your suggested change is
made in the fundamental workings of the slider, it will be impossible
for me to get what I want.

Therefore, you are asking for the slider to have *less* functionality
than it does now.

[snip]

> But a simple solution can exist: Have an option in the API to this
> UIcontrol to specify which way it should behave.

That would be fine as long as the default is the current behavior.

> So those who want deterministic behavior can choose that, and those
> who do not can choose that.
>
> Currently the way it works is broken IMNSHO. It forces the
> user who wants the slider to move only by certain minimum steps
> to do rounding on their end, when this was what the minor/major
> steps settings was supposed to do.

I think you're overstating your case. It's a minor problem at most,
with a trivial workaround.

[Nasser M. Abbasi]

On 3/3/2013 12:07 AM, Doug Schwarz wrote:

> But you can get what you want simply by
> rounding the slider value in the callback function.

I know. That is what I had to do.

>You want two levels
> of granularity and you can have them.
>
> I want three levels of granularity

No problem. There is a trivial solution to this.

Add a new option to allow user to specify either the "2 levels"
or the "3 levels". Make the default to be the "3 levels" so it
works as it does now.

This way the UIcontrol will be backward compatible. Old code
will work on new versions as is when this option is missing.

This way, a user does not have to do the rounding as this is
something that should be done inside the UI control based on
the minor step.

This way, you can have your 3 levels, and I can have my 2 levels.

But this is not a big deal for me actually, I do not do much Matlab
GUI any more. I was just playing around with some program and noticed
this strange slider result. I just like to complain when I see
something not right. I can't help it :)

--Nasser

[Steven_Lord]

"Nasser M. Abbasi" <n...@12000.org> wrote in message
news:kgu1cp$gqn$1...@speranza.aioe.org...

> On 3/2/2013 4:30 PM, dpb wrote:
>
>> Not to mention it would break the expected behavior users know from
>> other Windows apps where they can typically move the slider itself to
>> obtain yet more granularity than provided by the arrow/keyboard.
>>
>
> wow, That must be some really an amazing mouse/hand coordination
> where one can use the mouse to slide a slider by just say 0.0001 amount.
>
> How can this be possible? Can one actually control by hand the
> slider values to change by such a amout? Is this like super lazer
> type of mouse?

You'd be surprised. I've gotten very, very good at moving the lockpick one
click (which doesn't really appear to move the lockpick on the screen) in
the game Elder Scrolls V: Skyrim. And in some older games (like Myst) moving
the mouse over each individual pixel was sometimes necessary to figure out
how to proceed.

Beyond that there's always accessibility tools like Windows Magnifier, which
makes it easier to move pixel-by-pixel.

> But to obtain exact values from Slider, another simple solution
> (other than having an option as I said before) it to allow
> a small pop-up window to use to enter in it a more exact value
> whenneeded.

Since you feel strongly about this, I second dpb's suggestion. Please submit
this as an official enhancement request with the technical support staff so
they can enter it into the enhancement database as a user-requested
enhancement.

--
Steve Lord
sl...@mathworks.com
To contact Technical Support use the Contact Us link on
http://www.mathworks.com

[matt dash]

"Nasser M. Abbasi" wrote in message <kguto2$jkf$1...@speranza.aioe.org>...

All of this seems to be related to the fact that the matlab "slider" is not actually a slider at all, but a scrollbar. It is meant to represent a *range* of values, as indicated by the length of the knob. AFAIK it is based on java.swing.JScrollBar and works exactly like it should.

The real mystery is why MATLAB does not include a real slider uicontrol, based on java.swing.JSlider. This would behave the way you want it to.

It is, however, very easy to make your own. You just need to code the callback slightly differently since its first input will be a java handle, which you can't use with guidata.

An example:

function slidertest
figure;

[jslider hslider]=javacomponent('javax.swing.JSlider',[50 50 200 30]);
jslider.setPaintTicks(1)
jslider.setSnapToTicks(1)
jslider.setMinimum(1)
jslider.setMaximum(10)
jslider.setMajorTickSpacing(1);
jslider.setValue(5);
set(jslider,'background',java.awt.Color.white)
set(jslider,'StateChangedCallback',{@slider_Callback,hslider});

function slider_Callback(jsrc,jev,src)
handles=guidata(src);

%...

You may also want to include the line:
if jsrc.getValueIsAdjusting;return;end

at the beginning of the callback, so that it only runs after the user has stopped sliding it.