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).
Vern Jensen
The problem is that in certain situations I'm getting THREE keyUp/keyDown events when I push certain keys.
In my event code I added:
case SDL_KEYUP:
printf("SDL KeyScanCode for KEYUP event: %d\n", event->key.keysym.scancode );
…
and
case SDL_KEYDOWN:
printf("SDL KeyScanCode for KEYDOWN event: %d\n", event->key.keysym.scancode );
…
The result of one test run where I push 2 keys and then release them is this:
SDL KeyScanCode for KEYDOWN event: 92 // Pushed keypad 4
SDL KeyScanCode for KEYDOWN event: 83 // Pushed left shift
SDL KeyScanCode for KEYUP event: 83
SDL KeyScanCode for KEYDOWN event: 225
SDL KeyScanCode for KEYUP event: 92 // Released keypad 4
SDL KeyScanCode for KEYDOWN event: 83
SDL KeyScanCode for KEYUP event: 83
SDL KeyScanCode for KEYUP event: 225 // Released left shift
There *should* be only a total of 4 events above… 2 for each key being pushed, and 2 for each being released. But instead some bogus events for numlock being pushed/released are sent from SDL. These events did not occur. I did not push numlock. The value above for numlock is 83. Comments above show when I pushed each key. As you can see, when I push left shift, THREE events are instantly sent to my application, keyDown and then keyUp for numlock, and then the valid event for left shift (the key that was actually pushed).
You could replace keypad 4 with pretty much any keyPad key and it'll still happen. You can also replace it with any arrow key and it'll happen. However, when trying it with normal letter keys on the main keyboard it didn't.
It happens with other modifier keys too, not just left shift.
The order in which the keys are pressed matter. For instance, if I do:
1) keypad 4
2) left shift
3) release left shift
4) release keypad 4
Then at step 2, I get the 3 events above (when there should be only one), but steps 3 and 4 work properly… I don't get extra keyUp/keyDown events for steps 3 or 4. Thereas if the order of steps 3 and 4 are reversed, I get the bogus extra events for numlock.
Also, the problem can occur even when pushing just a single key by itself. If I push left shift, then keypad 4, then release left shift, then release keypad 4, then the following push of left shift will cause the bug. If I continue pushing and releasing left shift though, it won't happen again until I again involve keypad keys.
---
Sam Lantinga
According to the Apple documentation, NSNumericPadKeyMask is set for any arrow or numeric keypad event. Indeed this is what's happening.
I verified that we get the correct events for the numlock key and the mod state gets set correcly, so it should be safe to remove this bogus code.
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.
driedfruit
In X11_HideWindow, we call XUnmapWindow to unmap. According to ICCCN2.0, this should never happen, and XWithdrawWindow should be called instead.
http://www.tronche.com/gui/x/icccm/sec-4.html#s-4.1.4
"The reason for requiring the client to send a synthetic UnmapNotify event is to ensure that the window manager gets some notification of the client's desire to change state, ***even though the window may already be unmapped when the desire is expressed***."
Additionally, this can be observed at http://cgit.freedesktop.org/xorg/lib/libX11/tree/src/Withdraw.c#n65
Failure to comply leads to "MapNotify" event never appearing on non-reparenting WMs after subsequent show-hide-show requests. (I'm currently observing this behavior, thus my bug report).
Lee Salzman
I messed up in the patch I sent you regarding gobbling up the GLX error codes signaled when trying to create a context. After reading the spec I realized those error codes are relative to a base error that needs to be queried when setting up the GLX extension...
So I have made a patch that fixes it for a user I had who was still getting the bug with my old patch.
Without this patch my previous one won't work, so it is recommended to merge this...
This #errors if you're using an SDK or deployment target that is less
than 10.6 and 10.5, respectively, and cleans up uses of
MAC_OS_X_VERSION_MIN_REQUIRED and MAC_OS_X_VERSION_MAX_ALLOWED according
to those requirements.
That is, if you copy from the Windows clipboard and then launch Dota and then repeatedly paste to a terminal window then the text will disappear when Dota hits the timeout. If you then select on the Linux side you can repeatedly paste. If you select again on Windows then the text will get cleared again.
Note that Dota only looks at the clipboard when it has focus.
CR: Saml
This one is compliments of the FreeBSD buildbot finally having the
X11 libraries installed. :)
--HG--
extra : amend_source : f57bb1d54a19cb773358f8caefd40d477c01b05f
This wanted an EGLint*, not a VisualID* cast to an EGLint*.
Without this, 64-bit X11 fails here, because the datatype sizes are different.
Fixes Bugzilla 1686.
This fixes bug #1446. You can now create a window with SDL_CreateWindow(...,
SDL_WINDOW_MINIMIZED), and not have it immediately restore itself.
It also changes SDL_RaiseWindow() to be a no-op on minimized or hidden windows,
which is how it behaves on Windows.
This looks like the rest of the code doesn't deal with windows, and probably
just deals with a single fullscreen GLES context, like a console would, so
making setwindowgrab a no-op makes sense in this case; it's already "grabbed."
Fixes Bugzilla #1850.
--HG--
extra : rebase_source : 29b07b9c8378f69fb8b5f201584befd8d7f005dd
This is good policy, so it doesn't have a chance to leave it hidden on targets
that wouldn't necessarily reset it by default, but it also fixes a crash if
you try to use a message box after SDL_Quit() is called.
Fixes Bugzilla #1969.
Ryan C. Gordon
Cocoa_ShowMessageBox() ignores the "window" field of SDL_MessageBoxData, which means you can't assign a parent window to a message box. This is particularly egregious on Mac OS X, because it'll actually make the NSAlert visually part of the parent window instead of just concerning itself with window focus.
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.
Ryan C. Gordon
We have this in Cocoa_GL_SwapWindow()...
/* FIXME: Do we need to get the context for the window? */
[[NSOpenGLContext currentContext] flushBuffer];
...which means if the current GL context is not the one in (window), we swap a different one than requested.
Right now, we don't store information about which context is assigned to which window, and the OS doesn't give you a way to retrieve it from an NSView. We would have to track this per-window during SDL_GL_MakeCurrent() (and SDL_GL_CreateContext) calls.
