norfanin
SetupWindowData in SDL_windowswindow.c doesn't initialize two members of SDL_WindowData with NULL. This is an issue because other parts of the SDL code seem to make the assumption that this is the case. WIN_DestroyWindowFramebuffer for example uses data->mdc and data->hbm if they're not NULL.
Added a reference to SDL_Direct3D9GetAdapterIndex to SDL_test_common.c so SDL will fail to compile if the new symbol isn't included properly.
CR: Jorgen
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
This prevents a rogue call to SetWindowPos() from changing the state unexpectedly.
Also moved the size correction code above the window position query, because the initial window size can affect the positioning.
You should be able to do wglMakeCurrent(NULL, NULL), according to MSDN, since
the first parameter is ignored if the second is NULL, but this causes problems
on some drivers, so make sure we always have a valid HDC in the first
parameter (and exit early if we already have no current context in the
NULL, NULL case).
Sebastian
Setting a window icon works just fine until a renderer is added to the window.
After adding the renderer the icon disappears.
Reproduce by:
- Take the example code from the wiki: http://wiki.libsdl.org/moin.fcg/SDL_SetWindowIcon
- Add the following two lines after SDL_FreeSurface(surface);
SDL_Delay(1000);
SDL_Renderer* ren = SDL_CreateRenderer(window, -1, SDL_RENDERER_ACCELERATED);
-compile and run
You will see the window icon correctly at first. After the Delay the Icon will disappear.
norfanin
There are a few potential buffer overflows in the Windows IME code located in the SDL_windowskeyboard.c file. [1] They mainly happen because the code passes the number of bytes instead of the number of characters to the wide-character string functions wcslcpy and wcslcat. In another place, the code assumes that the composition cursor position can never go beyond the size of the composition string buffer.
Some of these overflows and overruns can occur with the Japanese IME on Vista and simplified Chinese IME on XP. I don't actually speak those languages and it's my first time using the IMEs, so I probably pushed them to the limit where nobody would still be compositing proper words. They don't cause any immediate access violation, although the possibility of trashing the SDL_VideoData structure is never good.
I've attached a patch that fixes those I found, but because I'm very new to the code it may be worthwhile if someone else also has a look over the code.
I'll go over the changes in my patch and explain what, why and how.
In the function IME_GetReadingString, there is a wcslcpy to copy the reading string from the IMC memory to the SDL reading string buffer. [2] This assumes that the length of the reading string never exceeds the SDL buffer size. I guess that is possible and I wasn't able to get a long reading string in my tests, but the patch adds a simple check anyway.
In the function IME_GetCompositionString, the first line calls ImmGetCompositionStringW to get the composition string. [3] The Microsoft documentation states that the fourth argument is for the destination buffer size in bytes (even with unicode) and the code correctly passes the value of sizeof. However, at the end of IME_GetCompositionString, the string is terminated by setting the element at index 'length' to 0. 'length' is calculated by dividing the number of bytes (those written by ImmGetCompositionStringW) by 2. If it managed to write 64 bytes, the code sets element 32 to 0, which would be the beginning of the reading string if the alignment places it there. My patch adds a subtraction to the fourth argument, essentially making it always pass 62 instead.
In the same function, the code assumes that the composition cursor position doesn't go beyond the buffer size. [4] My patch adds a simple range check in front of the indirection.
In the function IME_SendEditingEvent, the size for the wide-character string functions is passed in bytes instead of characters. [5] Oddly, the current code subtracts 'len' from the size in one function call. This results in truncation in certain situations as the third argument is the number of characters available in the destination buffer. If I'm understanding it correctly, this is supposed to copy x characters of the composition buffer, then concatenate the whole reading string buffer, and then the rest of the composition buffer (where x is the composition cursor position). I don't see how a truncation of the rest would be helpful here. Perhaps this is just an error? My patch removes the subtraction.
In the function UIElementSink_UpdateUIElement, bytes instead of characters is used again for a wcslcpy call. [6]
The SDL OpenGL context code is now properly thread aware. There are two new functions which return the current OpenGL window and context for the current thread.
There are still places in the cocoa driver where the OpenGL context needs to be updated when the view changes. These will need a different solution and still use the last globally set context to avoid changing behavior.
We now do FULL or NO accel based on the app's preference. If the app didn't
specify, we do FULL then fall back to NO.
(Not specifying anything--a true "don't care" scenario--breaks some ATI
drivers, so we try to keep to the spirit of it while forcing a specific
state.)
Previously, it would always do FULL, and try NO if it failed and the app
had requested NO or DONTCARE.
This is a transplant of hg changesets a04171d6fa11 and d0b7c45e982e from the
SDL-1.2 branch.
Fixes Bugzilla #1254.
--HG--
extra : rebase_source : db951d96e685e17a4d71fe2aa3d65043661ccccc
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.
Ryan C. Gordon
With this function...
SDL_UpdateWindowSurfaceRects(SDL_Window * window, SDL_Rect * rects, int numrects);
...is there any reason rects isn't "const SDL_Rect *" ?
* 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
