Community
Participate
Working Groups
Build Identifier: 20100617-1415 The ScaleFieldEditor sets the minimum and maximum values incorrectly for the Mac platform. It sets minimum before maximum, ensuring that minimum never moves from the default zero value. I.e.: private void updateScale() { if (scale != null && !scale.isDisposed()) { scale.setMinimum(getMinimum()); scale.setMaximum(getMaximum()); scale.setIncrement(getIncrement()); scale.setPageIncrement(getPageIncrement()); } } Reproducible: Always Steps to Reproduce: It should set the maximum *before* setting the minimum. I.e.: private void updateScale() { if (scale != null && !scale.isDisposed()) { scale.setMaximum(getMaximum()); scale.setMinimum(getMinimum()); scale.setIncrement(getIncrement()); scale.setPageIncrement(getPageIncrement()); } } This change is needed to make the ScaleFieldEditor work properly on Mac. The other option is to set the minimum, set the maximum, and then check and set the minimum again if it hasn't taken. This though seems pointless.
Note, this is because on the Mac, if the minimum is greater than the maximum, then the minimum is not set. Not sure if this is the correct platform behavior.
Simon, are you using Carbon or Cocoa? Or does the bug appear on both windowing systems? (In reply to comment #1) > Note, this is because on the Mac, if the minimum is greater than the maximum, > then the minimum is not set. Not sure if this is the correct platform behavior. SWT team, please advise if this is an SWT bug or something enforced by the platform.
Cocoa. In Scale.setMiniumum(int value) the code reads: public void setMinimum (int value) { checkWidget(); int maximum = (int)((NSSlider)view).maxValue(); if (!(0 <= value && value < maximum)) return; ((NSSlider)view).setMinValue(value); } So, if minimum is greater than value, minimum will never be set. Oops. :-)
I meant ... if value is greater than maximum, minimum will never be set to value.
How is this different than what we are doing on Win32? The if test is inverted (compared to Cocoa) but the logic appears to be the same.
(In reply to comment #5) > How is this different than what we are doing on Win32? The if test is inverted > (compared to Cocoa) but the logic appears to be the same. Then I guess this is an issue with ScaleFieldEditor and not The Cocoa implementation of Scale– which is what I thought. So if the logic is the same across platforms, the fix is to set the maximum before the minimum in ScaleFieldEditor.updateScale(). Even if it were *not* the case across platforms (and let's suppose for argument that it's not), the logic of setting the upper bound of the Scale first and then setting the lower bound (i.e. creating a wider range first before narrowing it), will still work on these platforms.
(In reply to comment #6) > Then I guess this is an issue with ScaleFieldEditor and not The Cocoa > implementation of Scale– which is what I thought. > > So if the logic is the same across platforms, the fix is to set the maximum > before the minimum in ScaleFieldEditor.updateScale(). Yep, I agree. Back to platform-ui.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
