Andreas
The issue comes down to this line on MSDN:
"TranslateMessage produces WM_CHAR messages only for keys that are mapped to ASCII characters by the keyboard driver."
"WM_KEYDOWN and WM_KEYUP combinations produce a WM_CHAR or WM_DEADCHAR message. WM_SYSKEYDOWN and WM_SYSKEYUP combinations produce a WM_SYSCHAR or WM_SYSDEADCHAR message."
Except for WM_CHAR, none of these messages are used in SDL. Hence TranslateMessage should be dropped entirely and proper handling be included in the WM_KEYDOWN event.
Currently TranslateMessage is called for every message even if it must not be called in certain cases (like "An application should not call TranslateMessage if the TranslateAccelerator function returns a nonzero value.").
WM_CHAR message handling should remain for external processes posting these messages - additionally, WM_UNICHAR should be added.
I made a patch for src/video/windows/SDL_windowsevents.c that seems to work fine. It doesn't solve the "missing" composition for Khmer, but at least input for languages that cannot be mapped to ASCII characters (and for which IME is not used) will now work on Windows.
--HG--
extra : rebase_source : 7024be6c3a874d0319ea4c65b7d43f105915288f
buckyballreaction
On some Windows systems, when switching from fullscreen to windowed mode in my game, the CPU will spike and the application never shows the window again.
See the part of the e-mail thread here:
http://lists.libsdl.org/pipermail/sdl-libsdl.org/2013-June/088626.html
I change the window by calling:
SDL_SetWindowFullscreen(gScreenInfo.sdlWindow, SDL_FALSE);
SDL_SetWindowSize(gScreenInfo.sdlWindow, sdlWindowWidth, sdlWindowHeight);
which you can see in our source:
https://code.google.com/p/bitfighter/source/browse/zap/VideoSystem.cpp#377
Then all of a sudden the application gets stuck in WIN_PumpEvents() in SDL_windowsevents.c. I turned on WMMSG_DEBUG and found that there was an endless stream of WM_EVENT messages. I also found that where WM_PAINT is being handled in the callback WIN_WindowProc(), ValidateRect is somehow not clearing, or it is persisting, the WM_EVENT message like it's supposed to (according to the docs).
This may be a hardware issue. The issue has appeared on three different systems, one of them sporadically:
- Windows XP SP3 running in VMware 9.0 (without VMWare 3D acceleration, but with the tools and drivers installed), Host: openSUSE 12.3 x86_64, NVidia NVS 3100M
- Windows XP SP3 64bit running in VirtualBox, Host: Debian Wheezy (stable), Mobility Radeon HD 4100 (this was the sporadic one)
- Windows 7 64 bit, Radeon 6770
This fixes an issue where we were using the wrong macros to extract the position from WM_MOUSEMOVE, so negative values were behaving incorrectly.
These would be generated in multimon situations, or if you use SetCapture.
Fixes http://bugzilla.libsdl.org/show_bug.cgi?id=1175
We get an WM_MOUSELEAVE when we switch to relative mode, even though the cursor is still in the window.
Ignoring this event to not end up with a NULL mouse focus.
This fixes http://bugzilla.libsdl.org/show_bug.cgi?id=1861
Fix numlock and pause keys not being pressable on win32, they both report under
the same scancode, so use the VK to tell them apart
--HG--
extra : histedit_source : ea129a468bd8ca3164b1aaea0fa143cf2e130b7b
This lets us change things like this...
if (Failed) {
SDL_SetError("We failed");
return -1;
}
...into this...
if (Failed) {
return SDL_SetError("We failed");
}
Fixes Bugzilla #1778.
* Normalized touch coordinates as floats in the 0...1 range
* Removed unused touchpad concepts from the API
* Added API functions to get active touch devices and current finger state
- more scancode goodness, removing now dead wparam translation code
- add scancode for SDL_SCANCODE_NONUSBACKSLASH
- don't translate sdl key values for numeric and grave key
CR: SamL
Marco Schmidt
After sizing my main window (the only window in my application) through
grabbing the window border with the mouse the window collapses instantly to a
size of 0 x 124. In my application I can not resize the window to a normal size
again.
I tried to reproduce the problem - and here a the minimal steps I found.
I'm running WIN8 x64, VS2012Pro, HG SDL-2.0 tip, WIN32-Build.
Minimal steps to reproduce my problem:
- open solution SDL_VS2012
- make testdraw2 the start project
- pass command line option --resize to the debuggee testdraw2
- starting the application testdraw2
- try to resize the window
- the application window resizes to a minimal size 0 x 124.
- the application crashes to divide by zero .... (this is only the aftermath
but a unhandled error condition)
- Added new SDL_HINT_ALLOW_TOPMOST hint, when set to "0" then never set the topmost bit on a window. Useful when debugging fullscreen issues.
- fixed crash in windows joystick scanning if we failed to load the xinput dll
- added support for SDL_WINDOW_FULLSCREEN_DESKTOP under windows
- synthesize relative mouse movements if directinput fails to send relative moves, happens under virtual box.
Philipp Wiesemann 2012-09-30 05:56:09 PDT
I attached a patch which tries to implement the dropfile support for Microsoft
Windows. If applied SDL_DROPFILE events should be sent for single or multiple
files which are dropped on window.
The handling on Windows side is always activated (cursor will change and so on)
because there is no connection between SDL_EventState() and the window setup. I
assumed this additional overhead would be small and can be ignored.
It's a long-dead platform, and we don't have any way to build for, test, or
maintain it, so there's no sense in doing acrobatics to support it.
If you need Windows CE support, use SDL 1.2. If you need Windows Phone support,
send SDL 2.0 patches for the newer Windows Mobile platform.
Here is my first rough attempt. "testrelative" feels right to me, but I'd like it someone else tested this, especially compared to Linux/OSX. The "Ctrl+r" to switch between relative and normal mouse movements seems to work flawlessly. With relative mouse movement, the only way to change focus is via keyboard. I'm not sure if that is the correct approach, but that would seem to be the most useful mode for games. Still, if my assumption is wrong, I can fix that no problem.
