5. A modeless window should release focus when it has
done its immediate job - it must not hold focus assuming the user will want it
in that window again. This includes the focus given to a modeless top level
window (e.g. colour editor) when it is dragged by its title bar - if it's not
going to use that focus it should hand it back to the previous owner so that
focus indication correctly shows where focus really is. The meaning of
"immediate job" is defined by the window but a typical example is when the
user presses Return after entering text into an edit control.
[Charles
Moir] To clarify this means that dragging the colour editor, or any
modeless dialog, would return focus on the drop (as the current colour editor
does actually)
6. The user must be warned about any destructive
operation caused by a keypress in a modeless window (unless the data concerned
is owned by the window itself).
[Charles Moir] I don't understand this
one. It's generally thought that good UI should not warn the user about
operations that change data, because that's what Undo is there for.
Ah, by destructive you mean really destructive, specifically
that it destroys the undo record?
7. A window only gets focus as the result of
deliberate action by the user such as clicking or pressing tab.
[Charles
Moir] How would tab transfer focus to a window that didn't already have
it?
The application should never move focus into a
modeless window by itself.
8. A window should not take focus if it has no use
for keypresses. Further, a control in a modeless window should only take focus
if keypresses are essential to its operation.
9. A window should indicate whether it owns or
contains input focus (or not) in the standard way for the native OS. This is
usually indicated using the title bar or tab control.
[Charles
Moir] Except docked windows appear not to do
this