Opened 13 years ago

Closed 10 years ago

#4555 closed defect (fixed)

wxSlider cannot reach full area on OS/X

Reported by: slvrrose Owned by:
Priority: normal Milestone: 3.0.0
Component: old wxOSX/Carbon port Version: stable-latest
Keywords: wxSlider Mac OSX max maximum Cc: slvrrose, bcomeara
Blocked By: Blocking:
Patch: no

Description

I encountered this bug in wxPython; not sure if exists in wxWidgets as a whole. The thumb on wxSlider components on OS/X cannot be dragged all the way to the right. This problem can be viewed in the Slider demo code in the wxPython DEMO, for example, where the nominal range of the slider is 1-100. On OS/X, the furthest right I can drag the slider is 98.

Change History (12)

comment:1 Changed 13 years ago by bcomeara

This IS true for wxWidgets as a whole for Mac. I've posted about it at http://wxforum.shadonet.com/viewtopic.php?t=18194 ; slider fails in both the controls and widgets examples.

comment:2 Changed 13 years ago by bcomeara

Note that the bug title should be wxSlider (searching for wxSlider does not find this bug, but searching for slider does).

comment:3 Changed 12 years ago by wojdyr

  • Component set to wxMac
  • Keywords wxSlider added

comment:4 Changed 10 years ago by wxsite

  • Keywords Mac OSX max added
  • Summary changed from wsSlider cannot reach full area on OS/X to wxSlider cannot reach full area on OS/X

comment:5 Changed 10 years ago by disc

  • Component changed from wxOSX-Carbon to wxOSX (any toolkit)
  • Keywords maximum added
  • Milestone set to 3.0
  • Status changed from new to confirmed
  • Version set to 2.9-svn

If Full Keyboard Access (see Apple Menu -> System Preferences) is set to "All controls" then the wxSlider can't be set to its highest value using the mouse. This can indeed be reproduced using the slider on the default page of the Widgets sample. The maximum it can reach is 98, instead of 100.

Workarounds are to set Full Keyboard Access to "Text boxes and lists only" (use Control+F7 to switch between the two keyboard settings). Also locally I have been using a modification to wxMacControl::CanFocus in src/osx/carbon/window.cpp . Basically if I return false there (which boils down to the first workaround) then the maximum value can be reached (but then almost no controls support tabbing). I haven't been able to figure out how this is related.

This also occurs in wx 2.8, and applies to at least OS X 10.4-10.6.

comment:6 Changed 10 years ago by csomor

I cannot reproduce this under osx_cocoa, Dimitri, can you give me instructions for this ? Thanks

comment:7 Changed 10 years ago by disc

Sure, I tried again just now. I have a clean svn checkout of r67401. I used ../configure without any options this time (formerly I tried with --enable-debug --disable-shared). Make the library and then make samples/widgets/. I "open ./widgets.app" and activate the sliders page (formerly I said using the default page of the Widgets sample, but it actually remembers what page was last used). Using the mouse I can't put the slider to the maximum value of 100. Note that it does work using the keyboard with Cursor Up.
A requirement for this is to have Full Keyboard Access set to All Controls. You can verify this using the Terminal:

defaults read -g AppleKeyboardUIMode

It should return 2 (and not 0). If I forcibly set it to 1 then the error also occurs.

Yesterday I noticed that after I switched from wx 2.8 to 2.9 I didn't include the workaround anymore in my own code but the sliders did work correctly. I thought maybe it had to do with other controls the sliders are inside but just now I added widgets.cpp and slider.cpp from samples/widgets/ to my Xcode project and then it works fine! So apparently it has to do with a difference between configure based building and using Xcode (did you hapen to try with Xcode?). Note that back when I was using 2.8 I also used Xcode so something changed since then. If you don't have any idea what it might be (a difference between preprocessor defines?) I can try to figure out where the difference is between the two.

comment:8 Changed 10 years ago by csomor

if I try the Apple Supplied Appearance Sample I get exactly the same problem (only draggable to 247 instead of 255), but only if all of the following are true

  • full keyboard access is on
  • the control has the focus
  • live feedback is requested

it only happens with all sliders in the appearance pane (the vertical ones only lower down to 12 instead 0, but in essence it is the same), so it shows that this definitely is an OS problem, the maximum achievable in this case is depending on the max value and the true size of the control

the funny thing is that in appearance sample it isn't easy to really push the focus on this control, maybe this is the reason why it is not noticed more frequently

so I guess we have two options, either forget about the live feedback, or make sure that the control cannot ever get the keyboard focus ...

comment:9 Changed 10 years ago by vadz

Could we turn the live feedback off dynamically when the control gets focus (and restore it when it loses it)? If not, I guess the most Mac-ish solution would be to prevent it from getting focus at all when full keyboard access is on as I think many more Mac users will be upset that if they can't use the mouse to drag the slider to the maximal value than that they can't use the keyboard with it (although I personally will definitely be in the latter category...).

comment:10 follow-up: Changed 10 years ago by disc

  • Component changed from wxOSX (any toolkit) to wxOSX-Carbon

I was under the very wrong impression that a default configure build would use Cocoa, but it does not and still uses Carbon. I'm very sorry for the confusion. I now configured using --with-osx_cocoa and the problem does not exist then (I had to remove linking with the adv library which does not build for x86_64 and then only compile with slider.cpp and widgets.cpp for the Widgets sample).
Is the Appearance sample you tried Carbon-based as well?

I prefer being able to have live feedback and would find it less disastrous (for OS X which IMHO doesn't have very good keyboard navigation support) if a wxSlider can't have focus. What do you think? In case live feedback can't be changed dynamically I could make a simple change that adds a wxSlider::AcceptsFocus which always returns false (needed for Carbon builds only). As Vadim hinted, I don't think it's useful to do it conditionally because when Full Keyboard Access is disabled it can't seem to have focus anyway.

comment:11 in reply to: ↑ 10 Changed 10 years ago by csomor

Replying to disc:

Is the Appearance sample you tried Carbon-based as well?

as carbon as it can be yes, AppearanceSample started as a MacOS classic app in 1997, and was then updated for carbon events etc... so the version I used is called AppearanceSampleUpdated and dates from about 2005

I'll avoid the focus then, thanks for voicing your opinions

comment:12 Changed 10 years ago by SC

  • Resolution set to fixed
  • Status changed from confirmed to closed

(In [67416]) workaround OSX bug, fixes #4555

Note: See TracTickets for help on using tickets.