At 12:17 05/01/01 +0900, Stephen J. Turnbull wrote:
>>>>> "Andy" == Andy Piper
Andy> I'll see if I can implement focusable soon. But the holidays
Andy> are over and I just ran out of hacking time. Always dropping
Andy> focus is defitinely the wrong default option.
I think something must be missing here. I find it hard to imagine a
_button_ that should retain focus after activation _by default_.
Buttons normally invoke actions; it's unusual (though plausible, see
below) that you would want to invoke the same action twice in
succession, with no intervening actions in other widgets. I would
assume the button's _parent_ should then get focus. AFAICT, this is
actually what happens in MS Windows (after 5 minutes of experimenting
with the file browser, and it's been years since I actually used
How did you verify this? I see exactly the opposite - buttons get focus
when you click. If you look at the mswindows documentation it tells you
that this is what happens by default - and also you can't turn it off!
It seems to me that rather than implement a "focusable"
buttons should relinquish focus by default, and if they want to keep
it, they should have to explicitly call a function to warp it back to
themselves as part of their action. "Always dropping focus is
definitely the right default action." :-)
Couldn't agree less.
OTOH, if I _click_ on that button, and want to repeat, why would I
switch from the mouse to the keyboard? IMHO, retaining focus for this
purpose is far less useful than relinquishing it. Note further that
in this kind of application, the text widget invariably provides
keyboard equivalents for the button.
I'm not trying to justify it, just noting what happens and asserting that
we should do the same.
Finally, if a button is part of a dialog, then I agree that the
should retain focus if the activation of that button does not pop down
the dialog. The dialog may very well choose to assign focus to the
last clicked button. But shouldn't that be decided according to the
policy of the dialog, and not be hard-coded into button behavior? For
example, in a file selector dialog, when I hit the "parent" button, I
do not want the parent button to have focus. I want to be able to
type into the text field.
These are toolbar buttons which are different. We are talking about buttons
in general (and mostly in the context of dialogs)
Try this: enter the windows file browser. go down two directory
levels anywhere. click on the parent button. now hit return. What
happens? _nothing_, because you haven't selected anything in the
browser window yet. You definitely don't go to parent again.
See above. Try playing about with some dialogs and clicking `apply' say.
I can't believe that this is somehow left up to programmer
in the MS Windows interface. Surely Microsoft forces some policy,
which the programmer can override.
It forces focus to the button and you cannot override it.
Dr Andy Piper
Principal Consultant, BEA Systems Ltd