We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

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?

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

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

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

(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?