Ctrl+Tab shortcut

Hi All:

    I've recently discovered, to myself, a handy shortcut for the Tab (aka
Tabstrip, TabView) control.
    If in any windows app which uses Tabs (e.g. Display Properties), i press
Ctrl+Tab, it changes the current tab and focus on the next tab. The
interesting thing in this shortcut, is that it doesn't sets the focus on the
flap itself and sets the focus on the first control (view) in the content of
such tab.
    Happy with the discover, i went to test it on my Dolphin smalltalk, and
I've found that it doesn't work exactly as in most windows apps, it sets the
focus on the flap, but keep the focus on that flap, forcing me to change to
the next flap manually and then to the first view in the control. As far as
i could saw, it implements the standard windows control, but i didn't found
what makes it work in a different way.

    Any clues? Any way to "fix it" and make it work as all the others
windows apps without "breaking" (taking it lightly) the metaphor?

    Thanks in advance.

--
Esteban.

"Esteban A. Maringolo" <[hidden email]> wrote in message
news:[hidden email]...
It's true that Ctrl+Tab is listed as a standard key for moving to the next
tab in a tabbed dialog, but it is also listed as a standard key for moving
to the next "pane". From "Guidelines for Keyboard User Interface Design" on
MSDN:

"The following keystrokes are used for moving between panes within a window:
  a.. The TAB key moves the input focus to the next area of an active pane
only if it is not used by any other controls within the window.
  b.. The CTRL+TAB shortcut keys or F6 function key moves the input focus to
the next pane or palette. ..."

Windows' own dialog navigation seems to interpret Ctrl+Tab the same as Tab
(in many applications it does precisely that, e.g. Explorer) , so
unfortunately we made the same interpreation in the early days of Dolphin,
and so used Ctrl+Tab as a way to allow tabbing out of a edit field that
wants to use the Tab key for the input of tab characters. I'm not sure we
could change that now in the base system without adversely affecting
existing applications, though you are free to do so if you wish (just delete
TextEdit>>preTranslateKeyboardInput:).

I don't think the navigation between tabs is implemented by the Tab control
itself, but is something that is an application responsibility. As far as I
can tell the Tab control only processes the cursor keys when it itself has
focus, and it ignores the Ctrl[+Shift]+Tab and Ctrl+PgUp/PgDown key presses.

Dolphin uses the IsDialogMessage() Win32 API to implement standard (dialog
type) keyboard navigation across all top-level views (not just Dialogs), and
as mentioned this will absorb Ctrl+Tab and attempt to use it for navigation
between controls. This keyboard navigation is effectively performed at a
higher priority than any actions related to keyboard input that might be
performed by controls, because it is performed before the messages are
dispatched to the controls. This is useful in that it means any accelerator
keys you define (for example) will take precedence over any built-in
association a control might have for that key sequence. You can create your
own ShellView subclass and override #preTranslateKeyboardInput: should you
wish to disable the standard dialog-style navigation.

>    Any clues? Any way to "fix it" and make it work as all the others
> windows apps without "breaking" (taking it lightly) the metaphor?

Well you could file in the attached patch to TabView which makes it
implement Ctrl+Tab navigation itself at the pre-translate stage. I don't
think you will find this 100% satisfactory though, since Ctrl+Tab may still
only work reliably when focus is on the TabView itself. If you have a
TextEdit view on the tab, and its wantTab flag is true (the default for
multiline text edits), then as described above it itself handles Ctrl+Tab to
switch to the next control on the page as a normal Tab sequence will get
entered into the text in the view. This patch also enables the alternate
Ctrl+PgDown and Ctrl+PgUp shortcuts, and these will be more likely to work
since they don't tend to clash with other uses.

Regards

Blair
-------------------
!TabView methodsFor!

preTranslateKeyboardInput: aMSG
 "Answer whether the receiver would like to consume the argument aMSG,
 which is a keyboard message."

 | vk |
 vk := aMSG wParam.
 ((vk == VK_TAB or: [vk == VK_PRIOR or: [vk == VK_NEXT]]) and: [Keyboard
default isCtrlDown])
  ifTrue:
   [
    aMSG message == WM_KEYDOWN
    ifTrue:
     [| index |
     index := self selectionByIndex.
     index := (vk == VK_PRIOR or: [vk == VK_TAB and: [Keyboard default
isShiftDown]])
        ifTrue: [index = 1 ifTrue: [self size] ifFalse: [index - 1]]
        ifFalse: [index \\ self size + 1].
     self selectionByIndex: index].
   ^true].
 ^false! !
!TabView categoriesFor: #preTranslateKeyboardInput:!public! !

!CardContainer methodsFor!

preTranslateKeyboardInput: aMSG
 "Answer whether the receiver would like to consume the argument aMSG,
 which is a keyboard message."

 ^self tabs preTranslateKeyboardInput: aMSG! !
!CardContainer categoriesFor: #preTranslateKeyboardInput:!public! !