Sun, 29 Jan 2006 09:13:36 +0000Cleaned up the app registration stuff a bit
Sam Lantinga <slouken@libsdl.org> [Sun, 29 Jan 2006 09:13:36 +0000] rev 1288
Cleaned up the app registration stuff a bit

Sun, 29 Jan 2006 08:50:06 +0000Date: Tue, 15 Feb 2005 21:28:48 +0900 (JST)
Sam Lantinga <slouken@libsdl.org> [Sun, 29 Jan 2006 08:50:06 +0000] rev 1287
Date: Tue, 15 Feb 2005 21:28:48 +0900 (JST)
From: "Michael Leonhard"
Subject: [SDL] resize bug on Win32 and patch

This is my first post to this mailing list. In this email I will detail a
bug in the behavior of resizable SDL windows on Win32. Then I will
explain the solution and provide a patch.

Symptoms:

Under Windows, an SDL display created with the SDL_RESIZABLE flag exhibits
quirky behavior when being maximized. The window is resized to the proper
size, but it is shifted upwards about half the height of the title bar.
Similarly, a window whose origin is above the top of the screen will
spontaneously move its upper-left origin upon being resized. After two
such resize-induced moves, the title bar will be entirely off the top edge
of the screen. Subsequently, when the mouse is clicked and released on
the window border, the window will shrink its height spontaneously. This
height shrinkage occurs even if the user did not resize the border.

To observe this curious situation, please invoke:
SDL-1.2.8/test/testwm.exe -resize

Cause:

A pair of integers, SDL_windowX and SDL_windowY, are defined in
video/wincommon/SDL_sysevents.c. They are used by the DirectX video
driver and the DIB video driver:
video/windx5/SDL_dx5video.c
video/windib/SDL_dibvideo.c
As I understand the source code, the primary use of these variables is to
create a rectangle that represents the surface area in CLIENT SPACE.
Client space refers to a coordinate system that originates at the upper
left corner of a Win32 Window's drawable area. This is just inside the
window border and title bar. This client space rectangle, called bounds,
is subsequently converted to screen space with a call to
AdjustWindowRectEx. The problem is found in SDL's handling of the
WM_WINDOWPOSCHANGED message. According to MSDN,

"The WM_WINDOWPOSCHANGED message is sent to a window whose
size, position, or place in the Z order has changed as a
result of a call to the SetWindowPos function or another
window-management function."

I have confirmed that this message is indeed being sent to the SDL window
when the mouse is clicked on the window border, even if the window border
is not dragged.

In video/wincommon/SDL_sysevents.c, on line 464, in response to the
WM_WINDOWPOSCHANGED message, the (potentially) new client rectangle is
obtained. This rectangle is translated into screen coordinates and THEN
assigned to the SDL_windowX and Y variables. Thus screen coordinates are
being assigned to client coordinate variables. Once this is understood,
the solution is apparent: assign SDL_windowX and Y before translating the
rectangle to screen coordinates. This is accomplished by the following
patch.

-Mike_L

Sun, 29 Jan 2006 08:39:35 +0000Use the executable directory, not the current directory, for stdio output files
Sam Lantinga <slouken@libsdl.org> [Sun, 29 Jan 2006 08:39:35 +0000] rev 1286
Use the executable directory, not the current directory, for stdio output files

Sun, 29 Jan 2006 08:19:27 +0000*** empty log message ***
Sam Lantinga <slouken@libsdl.org> [Sun, 29 Jan 2006 08:19:27 +0000] rev 1285
*** empty log message ***

Sun, 29 Jan 2006 08:18:56 +0000Report both absolute and relative motion
Sam Lantinga <slouken@libsdl.org> [Sun, 29 Jan 2006 08:18:56 +0000] rev 1284
Report both absolute and relative motion

Sun, 29 Jan 2006 08:18:06 +0000Date: Fri, 14 Jan 2005 21:52:46 +0100
Sam Lantinga <slouken@libsdl.org> [Sun, 29 Jan 2006 08:18:06 +0000] rev 1283
Date: Fri, 14 Jan 2005 21:52:46 +0100
From: "SkunkGuru"
Subject: [SDL] Repeated mousemotion event on notebook

it seems that every ~500ms something fires a mousemotion event,
but with the same x and y position.
I tryed with both directx and windib video driver.

Sun, 29 Jan 2006 07:57:13 +0000Date: Sat, 15 Jan 2005 02:01:51 +0000 (UTC)
Sam Lantinga <slouken@libsdl.org> [Sun, 29 Jan 2006 07:57:13 +0000] rev 1282
Date: Sat, 15 Jan 2005 02:01:51 +0000 (UTC)
From: jimrandomh
Subject: [SDL] Re: Modifier keys pressed during initialization stick

I wrote a simple test program which initializes SDL, prints the SDL
version number, then prints any keydown and keyup events with their
modifiers. (Source code below). Compilation was done using Visual
Studio 6, release mode.

My test sequence was:
Start a command prompt. Type the name of the test program.
shift down
enter down (program starts)
Wait for window to appear
enter up
shift up
spacebar down
spacebar up

Under Windows 98, the output was correct:
SDL 1.2.8
left shift down
shift-return down
shift-return up
left shift up
space down
space up

Under Windows 2000 and under Windows XP, the output was:
SDL 1.2.8
shift-space down
shift-space up

Since shift was not held at the time space was pressed, this is
incorrect. Similar results were observed with launching in different
ways (including double-clicking in Windows Explorer), so it does not
depend on the launching terminal.

Sun, 29 Jan 2006 06:40:13 +0000*** empty log message ***
Sam Lantinga <slouken@libsdl.org> [Sun, 29 Jan 2006 06:40:13 +0000] rev 1281
*** empty log message ***

Sun, 29 Jan 2006 06:11:38 +0000Re-query the SDL_WINDOWID each time we initialize the video
Sam Lantinga <slouken@libsdl.org> [Sun, 29 Jan 2006 06:11:38 +0000] rev 1280
Re-query the SDL_WINDOWID each time we initialize the video

Sat, 28 Jan 2006 05:47:11 +0000*** empty log message ***
Sam Lantinga <slouken@libsdl.org> [Sat, 28 Jan 2006 05:47:11 +0000] rev 1279
*** empty log message ***