This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• Test which shows the problem. (test.cpp, text/x-c++src, 2016-11-22 20:12:52 +0000, 1387 bytes)

Reported in version: HG 2.1
Reported for operating system, platform: Windows (All), x86_64

Comments on the original bug report:

On 2016-11-22 20:12:52 +0000, echotangoecho wrote:

Created attachment 2639
Test which shows the problem.

When SDL_StartTextInput is called upon a key press of a character key on Windows, a SDL_TEXTINPUT event is received for this key, even though text input was not yet enabled when te key was pressed. The cause seems to be that TranslateMessage is called whether SDL_TEXTINPUT is enabled or not, causing a SDL_TEXTINPUT event to be generated when the WM_CHAR event is received after SDL_StartTextInput is called. The issue does indeed not seem to occur when TranslateMessage is only called if SDL_TEXTINPUT is enabled.

On 2017-08-11 20:18:21 +0000, Sam Lantinga wrote:

In SDL 2.0 text input events are enabled by default on the desktop. If you call SDL_StopTextInput() after creating your window, does that fix it for you?

On 2017-08-17 08:55:12 +0000, echotangoecho wrote:

That caused a related issue for us on Linux, but does not fix this on Windows. The exact problem in our case (0 A.D. / Pyrogenesis engine, also see bug report here: https://trac.wildfiregames.com/ticket/3870) is as follows: we use 't' as a hotkey to open a chat window, and when we call StartTextInput() upon a press of t, we don't expect to immediately also receive the character 't', we only expect to receive it upon repeat after StartTextInput() is called. The exact problem seems to be with this line: https://github.com/SDL-mirror/SDL/blob/f155bc23efc4734f96b021cf98b18843c87fd794/src/video/windows/SDL_windowsevents.c#L1016
A potential fix that has been confirmed to work for us is only executing this line if text input is actually enabled at this point -- The only problem with that is judging from the comment above this line it seems to be done intentionally...

On 2019-10-05 10:20:15 +0000, Castro B wrote:

@echotangoecho better this tahn nothing, I guess. ,https://couponaliexpress.nl/

On 2020-03-24 22:54:20 +0000, Ryan C. Gordon wrote:

(In reply to echotangoecho from comment # 2)

A potential fix that has been confirmed to work for us is only executing
this line if text input is actually enabled at this point -- The only
problem with that is judging from the comment above this line it seems to be
done intentionally...

So this popped up in the recently-changed bugs list, compliments of a spam comment, but in case this is something that's still bothering you:

Are you getting your SDL events through a function used with SDL_AddEventWatch()?

Because we should be way past the point where SDL_StartTextInput should be able to affect that keypress (the Windows event loop is long gone at this point, having copied SDL events to a queue for SDL_PollEvent() to find later), but I could see this happening in an event watcher, since your SDL_StartTextInput code would run before the event loop is complete.

--ryan.

On 2020-07-23 16:14:29 +0000, Imarok wrote:

(In reply to Ryan C. Gordon from comment # 4)

(In reply to echotangoecho from comment # 2)

A potential fix that has been confirmed to work for us is only executing
this line if text input is actually enabled at this point -- The only
problem with that is judging from the comment above this line it seems to be
done intentionally...

So this popped up in the recently-changed bugs list, compliments of a spam
comment, but in case this is something that's still bothering you:

Are you getting your SDL events through a function used with
SDL_AddEventWatch()?

Because we should be way past the point where SDL_StartTextInput should be
able to affect that keypress (the Windows event loop is long gone at this
point, having copied SDL events to a queue for SDL_PollEvent() to find
later), but I could see this happening in an event watcher, since your
SDL_StartTextInput code would run before the event loop is complete.

--ryan.

Yes this bug still happens and is bothering us.
I can't find a use of "SDL_AddEventWatch" anywhere in our code.
Btw: Have you seen the minimal working example uploaded by echotangoecho that shows the bug?