Having changed from using secondary dialogs with parent "0" (i.e., the desktop) to have the
main dialog as parent brought many improvements in screen behaviour, but it also semi-disables
the tab key when one of the child dialogs is active. With parent at zero, the tab key responded
normally; with main dialog as parent, no matter where on the screen an edit box has the focus,
the tab key takes focus to the first edit control on the screen, and further depressions of TAB
does nothing other than to make the highlighted (dark blue) area in this first edit control
flash.
All these edit controls are subclassed, in order ONLY to trap and respond to the ENTER key and
the cursor movement keys, and this works as before.
Does one now have to trap the TAB key and provide code to change focus in a logical way?
Any help will be greatly appreciated.
------------------
main dialog as parent brought many improvements in screen behaviour, but it also semi-disables
the tab key when one of the child dialogs is active. With parent at zero, the tab key responded
normally; with main dialog as parent, no matter where on the screen an edit box has the focus,
the tab key takes focus to the first edit control on the screen, and further depressions of TAB
does nothing other than to make the highlighted (dark blue) area in this first edit control
flash.
All these edit controls are subclassed, in order ONLY to trap and respond to the ENTER key and
the cursor movement keys, and this works as before.
Does one now have to trap the TAB key and provide code to change focus in a logical way?
Any help will be greatly appreciated.
------------------
Comment