Bug #270
closedWSlider setValue doesn't emit valueChanged
0%
Description
I'm setting a slider's value from an external source and I see that valueChanged does not emit on setValue() call.
I see it is emited from sliderReleased or something similar but it's not the expected behavior. My guess is that it hasn't been handled in other cases as well. Please make sure it will behave correctly next time
There should be a flag that indicates that no ui change was done emit valueChanged accordingly.
Right now I am doing this manually and from a design point of view it's not a good idea.
Here's a patch (untested but it works for another hack I did) to fix this issue:
WSlider.C
void WSlider::onSliderReleased(int u)
{
isUIChange = true; // should be declared as a private boolean and initialized as false
if (orientation_ == Horizontal)
u -= HANDLE_WIDTH / 2;
else
u = (int)height().toPixels() - (u + HANDLE_WIDTH / 2);
double l = (orientation_ == Horizontal ? width() : height()).toPixels();
double pixelsPerUnit = (l - HANDLE_WIDTH) / range();
double v = std::max(minimum_,
std::min(maximum_,
minimum_ + (int)((double)u / pixelsPerUnit
- 0.5)));
sliderMoved_.emit(static_cast(v));
setValue(static_cast(v));
valueChanged_.emit(value());
}
void WSlider::setValue(int value)
{
value_ = std::min(maximum*, std::max(minimum*, value));
updateSliderPosition();
if ( !isUIChange )
valueChanged_.emit(value());
else
isUIChange = false;
}
Updated by Koen Deforche about 14 years ago
- Status changed from New to Feedback
Omer Katz wrote:
I'm setting a slider's value from an external source and I see that valueChanged does not emit on setValue() call.
I see it is emited from sliderReleased or something similar but it's not the expected behavior. My guess is that it hasn't been handled in other cases as well. Please make sure it will behave correctly next time
There should be a flag that indicates that no ui change was done emit valueChanged accordingly.
Right now I am doing this manually and from a design point of view it's not a good idea.
Here's a patch (untested but it works for another hack I did) to fix this issue:
Hey Omer,
I still prefer to only fire signals when the user makes a change, not when you make a change through the API, since you may not always want the latter (e.g. to avoid recursions), and you can still do it by doing:
slider->valueChanged().emit(slider->value());
That way would work for you too, no ?
Regards,
koen
Updated by Omer Katz about 14 years ago
Koen Deforche wrote:
Omer Katz wrote:
> I'm setting a slider's value from an external source and I see that valueChanged does not emit on setValue() call.
> I see it is emited from sliderReleased or something similar but it's not the expected behavior. My guess is that it hasn't been handled in other cases as well. Please make sure it will behave correctly next time
> There should be a flag that indicates that no ui change was done emit valueChanged accordingly.
> Right now I am doing this manually and from a design point of view it's not a good idea.
> Here's a patch (untested but it works for another hack I did) to fix this issue:Hey Omer,
I still prefer to only fire signals when the user makes a change, not when you make a change through the API, since you may not always want the latter (e.g. to avoid recursions), and you can still do it by doing:
[...]
That way would work for you too, no ?
Regards,
koen
It's uglier. even an interface should do what it's expected to do.
setValue is meaningful, valueChanged.emit isn't.
If set the value I expected that valueChanged would be emitted, makes sense doesn't it? Just add a parameter to indicate that it will like you do in setInternalPath.
If you keep it this way it's a design problem.
Value can be changed from both ways.
And btw Recusion is just what I'm trying to do.
Updated by Koen Deforche over 10 years ago
- Status changed from Feedback to Rejected