1. tab control in *Dialog* boxes

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 sad .
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

new topic     » topic index » view message » categorize

2. Re: tab control in *Dialog* boxes

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 sad .

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

new topic     » goto parent     » topic index » view message » categorize

3. Re: tab control in *Dialog* boxes

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 sad .
>
>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 smile

All the best

Terry

new topic     » goto parent     » topic index » view message » categorize

Search



Quick Links

User menu

Not signed in.

Misc Menu