1. tab control in *Dialog* boxes
- Posted by Terry Moriarty <terry at EDERNEY.IDPS.CO.UK> May 25, 1999
- 451 views
- Last edited May 26, 1999
Hello everyone, I'm sure you've probably been through this before, but I'll tell you my problem anyway. I'm trying to make an *imitation* dialog box for a windows prog., mainly because after looking at the WIN32API.HLP definitions, making the *real* thing looks like the stuff of gods and fools . How can I catch the fact that the TAB key has been pressed from within an edit control? (so that I can move from one control to another). I've tried with wm_keydown, wm_char, and en_change and en_update from within wm_command, but have had no luck. I don't know if David has added feature this to his excellent win32lib, but it wouldn't help me as I have had to write my own lib anyway.( I needed more control over window styles etc.) . Any help that David or any others could offer would be greatly appreciated All the best for now Terry
2. Re: tab control in *Dialog* boxes
- Posted by "Cuny, David" <David.Cuny at DSS.CA.GOV> May 25, 1999
- 444 views
Terry Moriarty wrote: > I'm trying to make an *imitation* dialog box for a > windows prog., mainly because after looking at the > WIN32API.HLP definitions, making the *real* thing > looks like the stuff of gods and fools . Pretty much my reasoning for Win32Lib - dialogs really want to be built with resources, not from scratch. You'll probably have to emulate modality as well. >How can I catch the fact that the TAB key has been > pressed from within an edit control? ... I've > tried with wm_keydown, wm_char, and en_change and > en_update from within wm_command, but have had no luck. *scratched head in puzzlement* That's odd; iMsg = WM_KEYDOWN and wParam = VK_TAB are what Win32Lib look for. Here's the basic rundown. Win32Lib only uses a single callback for all the controls, called WndProc(). The first thing that WndProc tries to do is determine if it's supposed to be handling the event. Next, it decides if the receiver of the event is a window or a control. If it's not a window, it hands the event over to subclassed() to handle. The first thing subclassed() does is look at the iMsg parameter to see if it's got a WM_KEYDOWN, WM_KEYUP or WM_CHAR *and* a wParam of VK_TAB (#9). If it is, it goes into the tab key handler routine. The tab key handler only cares if it gets a WM_KEYDOWN. It calls GetKeyState to check if the shift key is pressed, does some calculations, and calls SetFocus to move to the next control. Perhaps you are trying to trap at the wrong level; the event is sent to the control, not the parent window of the control. > I don't know if David has added feature this to > his excellent win32lib, but it wouldn't help me > as I have had to write my own lib anyway. You might want to take a look at the Win32Lib code anyway, as a starting point. > ( I needed more control over window styles etc.) Win32Lib will let you pass the additional/overriding style parameters for windows and controls in the last parameter. And onEvent lets you trap Win32 events that are not built into Win32Lib. Good luck! -- David Cuny
3. Re: tab control in *Dialog* boxes
- Posted by Terry Moriarty <terry at EDERNEY.IDPS.CO.UK> May 26, 1999
- 435 views
On Tue, 25 May 1999 17:18:06 -0700, Cuny, David <David.Cuny at DSS.CA.GOV> wrote: >Terry Moriarty wrote: > >> I'm trying to make an *imitation* dialog box for a >> windows prog., mainly because after looking at the >> WIN32API.HLP definitions, making the *real* thing >> looks like the stuff of gods and fools . > >Pretty much my reasoning for Win32Lib - dialogs really want to be built with >resources, not from scratch. You'll probably have to emulate modality as >well. > > >>How can I catch the fact that the TAB key has been >> pressed from within an edit control? ... I've >> tried with wm_keydown, wm_char, and en_change and >> en_update from within wm_command, but have had no luck. > >*scratched head in puzzlement* > >That's odd; iMsg = WM_KEYDOWN and wParam = VK_TAB are what Win32Lib look >for. > >Here's the basic rundown. Win32Lib only uses a single callback for all the >controls, called WndProc(). The first thing that WndProc tries to do is >determine if it's supposed to be handling the event. Next, it decides if the >receiver of the event is a window or a control. If it's not a window, it >hands the event over to subclassed() to handle. > >The first thing subclassed() does is look at the iMsg parameter to see if >it's got a WM_KEYDOWN, WM_KEYUP or WM_CHAR *and* a wParam of VK_TAB (#9). If >it is, it goes into the tab key handler routine. > >The tab key handler only cares if it gets a WM_KEYDOWN. It calls GetKeyState >to check if the shift key is pressed, does some calculations, and calls >SetFocus to move to the next control. > >Perhaps you are trying to trap at the wrong level; the event is sent to the >control, not the parent window of the control. > > >> I don't know if David has added feature this to >> his excellent win32lib, but it wouldn't help me >> as I have had to write my own lib anyway. > >You might want to take a look at the Win32Lib code anyway, as a starting >point. > > >> ( I needed more control over window styles etc.) > >Win32Lib will let you pass the additional/overriding style parameters for >windows and controls in the last parameter. And onEvent lets you trap Win32 >events that are not built into Win32Lib. > >Good luck! > >-- David Cuny Thanks for the info David, hopefully have something to show for it before everything goes *ugh* 9/9/99 All the best Terry