DirectX keyboard problems with child windows

Cheers,

I have a SDL app (Win32) that uses embedded child windows (i.e. a text
entry dialog). Now I need to have the child windows receive keyboard
input. I’ve experimented around a lot, but cannot get keydown events to
the child windows. The SDL app seems to gobble them all up. Just setting
the focus manually doesn’t seem to work. The same behaviour is also
exhibited when I turn off DirectX (recompile with --disable-directx).

Is there any solution to this? I’d like the SDL window to behave a bit
more cooperatively with respect to key events …

One other thing I tried, is to send key events directly to the entry
window using SendMessage(). This sort of works for characters but
doesn’t work for “Enter”. The SDL scancode does not seem to match the
windows SendMessage() CHAR codes.

BTW, in Linux this works well. I’ve embedded some GTK widgets, pump gtk
events manually in the SDL display look and once I set the windows focus
to the gtk widget it works well and receives keyboard input.

Any hint is greatly appreciated!

Regards
Andreas

HI all,

in reply to myself - I figured it out (and found a small bug in SDL in
the process).

In three spots where DispatchMessage() is called the following line has
to be inserted before the DispatchMessage(&msg) to generate the proper
WM_CHAR messages for input boxen and alike.


TranslateMessage(&msg); // generate WM_CHAR messages

The source files that need changing are:
src/video/windx5/SDL_dx5events.c
src/video/windib/SDL_dibevents.c

Bye now
Andreas

Andreas Schiffler wrote:>

Cheers,

I have a SDL app (Win32) that uses embedded child windows (i.e. a text
entry dialog). Now I need to have the child windows receive keyboard
input. I’ve experimented around a lot, but cannot get keydown events to
the child windows. The SDL app seems to gobble them all up. Just setting
the focus manually doesn’t seem to work. The same behaviour is also
exhibited when I turn off DirectX (recompile with --disable-directx).

Is there any solution to this? I’d like the SDL window to behave a bit
more cooperatively with respect to key events …

One other thing I tried, is to send key events directly to the entry
window using SendMessage(). This sort of works for characters but
doesn’t work for “Enter”. The SDL scancode does not seem to match the
windows SendMessage() CHAR codes.

BTW, in Linux this works well. I’ve embedded some GTK widgets, pump gtk
events manually in the SDL display look and once I set the windows focus
to the gtk widget it works well and receives keyboard input.

Any hint is greatly appreciated!

Regards
Andreas

HI all,

in reply to myself - I figured it out (and found a small bug in SDL in
the process).

In three spots where DispatchMessage() is called the following line has
to be inserted before the DispatchMessage(&msg) to generate the proper
WM_CHAR messages for input boxen and alike.

Until character events are decoupled from the key down events (which is
planned for SDL 1.3) the Windows event loop is not supposed to call
TranslateMessage(). You have to enable unicode translation in SDL,
and read the unicode value from the key down event. See the plethora
of other posts on this topic for details.

See ya,
-Sam Lantinga, Software Engineer, Blizzard Entertainment

Sam,

whatever you say - you are the man.

But the fact remains, that a child window of the SDL window does not
receive any WM_CHAR messages unless the TranslateMessage() is done where
I pointed out.

And adding the TranslateMessage() does not seem to do any harm as far as
I can tell. The default SDL message loop still receives the keysyms as
before (Unicode is turned off - ie. the default).

As added modification you can simply ignore the WM_CHAR in just as the
WM_KEYDOWN messages are ignored (since “DirectX handles this”).

Basically WM_CHAR messages are required for any embedded dialog stuff
that uses entry lines (Form input in embedded browser, edit control in
embedded dialog, etc.). Typically a full-screen games doesn’t do this,
but I do in my application and there is use for this.

So I would add my vote for adding this as an optional compile time flag.

Cheers
Andreas>

HI all,

in reply to myself - I figured it out (and found a small bug in SDL in
the process).

In three spots where DispatchMessage() is called the following line has
to be inserted before the DispatchMessage(&msg) to generate the proper
WM_CHAR messages for input boxen and alike.

Until character events are decoupled from the key down events (which is
planned for SDL 1.3) the Windows event loop is not supposed to call
TranslateMessage(). You have to enable unicode translation in SDL,
and read the unicode value from the key down event. See the plethora
of other posts on this topic for details.

See ya,
-Sam Lantinga, Software Engineer, Blizzard Entertainment

Sam,

whatever you say - you are the man.

But the fact remains, that a child window of the SDL window does not
receive any WM_CHAR messages unless the TranslateMessage() is done where
I pointed out.

And adding the TranslateMessage() does not seem to do any harm as far as
I can tell. The default SDL message loop still receives the keysyms as
before (Unicode is turned off - ie. the default).

Ah, I see what’s happening.
The only drawback is the additional translation processing overhead.
Do you set the SDL window with SDL_WINDOWID? If so, I can special
case that to perform character translation … although I’m not sure
that’s the best way to handle it…

So I would add my vote for adding this as an optional compile time flag.

Okay, you want to submit a patch?

See ya,
-Sam Lantinga, Software Engineer, Blizzard Entertainment

Sam,

FYI, I am not using the SDL_WINDOWID hack. I create the SDL window first
and then query its hwnd using this code:

SDL_VERSION(&wmi.version);
if (!SDL_GetWMInfo(&wmi)) {
return (-1);
}
#ifdef WIN32
hwnd = wf->wmi.window;
#endif

Child windows have to be created in the main thread and the main event
loop need to do a bit more event pumping on all child windows to make
things fast enough (i.e. when embedding an IE browser).

As for a patch - my current SDL source tree has been to mocked around
with too much trying to chase this issue. I’ll have to reconstruct …
:slight_smile:

Ciao
Andreas>

Sam,

whatever you say - you are the man.

But the fact remains, that a child window of the SDL window does not
receive any WM_CHAR messages unless the TranslateMessage() is done where
I pointed out.

And adding the TranslateMessage() does not seem to do any harm as far as
I can tell. The default SDL message loop still receives the keysyms as
before (Unicode is turned off - ie. the default).

Ah, I see what’s happening.
The only drawback is the additional translation processing overhead.
Do you set the SDL window with SDL_WINDOWID? If so, I can special
case that to perform character translation … although I’m not sure
that’s the best way to handle it…

So I would add my vote for adding this as an optional compile time flag.

Okay, you want to submit a patch?

See ya,
-Sam Lantinga, Software Engineer, Blizzard Entertainment