[Date Prev][Date Next][Thread Prev][Thread Next][Thread Index]

RE: [XaraXtreme-dev] Galleries and focus handling

Charles,


* If a keyboard-editable control within a non-modal dialog
receives a return
  keypress, UNLESS IT PROCESSES THE KEYPRESS ITSELF it should
  commit the contents of the current field. [this handles the bar
  case]. If there is a default action (e.g. an apply button),
it should also
  perform that default action, in which case the default button should
  be highlighted in some way so it is obvious which "apply"
action will
  take effect. Examples of where a control processes return itself are
  (a) a multi-line text control where return should merely enter
  a return in the multi-line text field, (b) where the drop down list
  of a combo has been brought up, and return is used to select the
  item within the list.


A plain menu (e.g. font list) similarly i.e. you can select a menu, use
arrow keys, or type, and press Return,(or Esc) to action (or cancel) the
menu selection.


Sure. I was assuming all drop-downs were keyboard-editable controls.


* If a keyboard-editable control within a non-modal dialog receives an
  escape keypress, it should UNLESS IT PROCESSES THE KEYPRESS ITSELF
  cancel any changes to the current field (restoring it to
the previous
  value, and then return focus to the selected document. An example of
  a control processing the escape keypress itself would be a combo box
  where the drop down is popped up, where escape should close the
  drop-down (in this instance, a second escape would return focus
  to the document).


Whoa - what's the second Esc here?  Esc means cancel this operation and
return focus back to the main canvas (just as return mean action it and
return focus to the document). You can't have two Escapes to do this
(not the way it works right now - in any OS that I'm aware of). This is
standard OS behaviour actually.


The rationale was how it works by default. If you pop up the menu,
the first escape gets rid of the menu and returns the focus to
the control/dialog. The second does the normal dialog thing (mostly
close the dialog).

That's how Xtreme works at the moment in normal combos (see the align
dialog). It's also how I thought the colour editor works though I think
I'm mistaken and it's really that the second escape is clearing the
selection.

So you are probably right. Escape is not specially processed. It simply
cancels the current edit and returns focus to the selected document. So
the example should go. I think the bit marked "UNLESS IT PROCESSES"
should go to. So it should read:

* If a keyboard-editable control within a non-modal dialog receives an
 escape keypress, it should cancel any changes to the current field
 (restoring it to the previous value, and then return focus to the
 selected document.


And for clarification this applies to all menus, whether Combo box menus
or plain menus.


Sure. Internally they are all combo-boxes anyway (so we can use
wxODComboBox). In fact I have forgotten to set CB_READONLY on rather
a lot of them it seems (oops - I shall have to fix that).

Alex