SetVideoMode triggers VIDEORESIZE Win7 (1.2.15)

Bug reported #1544.
http://bugzilla.libsdl.org/show_bug.cgi?id=1544

The 1.2 / default (2.0/1.3) branches are confusing me, the changeset I
cited was in 2.0

Le 18/07/2012 22:25, Patrick Baggett a ?crit :> D’Archivio,

If you report the bug then I’ll see if I can come up with an
appropriate patch and attached it to bugzilla.

Patrick

On Wed, Jul 18, 2012 at 3:17 PM, Sam Lantinga <slouken at libsdl.org <mailto:slouken at libsdl.org>> wrote:

The intent is that you only get the resize event if the window
size is changed outside of SDL_SetVideoMode().  If it's not
working that way, it's a bug.  I don't have access to a windows
machine at the moment, so patches (and a bug report in
http://bugzilla.libsdl.org) are welcome.

On Mon, Jul 16, 2012 at 5:15 PM, Patrick Baggett <baggett.patrick at gmail.com <mailto:baggett.patrick at gmail.com>> wrote:



    On Wed, Jul 11, 2012 at 12:46 PM, D'Archivio Thibault <@Thibault_D_Archivio <mailto:@Thibault_D_Archivio>> wrote:

        Le 11/07/2012 19:20, Patrick Baggett a ?crit :
        Suppose there is a program "Super Blah Game", that links
        to SDL.dll. You can't change the code, just SDL.dll

        Then, if the game's code was:

        int g_width = -1, g_height = -1;


        /* ... some menu where user picks screen size ... */
        int w = userSelectedMode.width;
        int h = userSelectedMode.height;

        SDL_InitVideo(... SDL_FULLSCREEN ... );
        SDL_SetVideoMode(..., w, h, ... );



        /* ...Event handling... */
        case SDL_VIDEORESIZE:
            g_width = event.resize.x;
            g_height = event.resize.y;

        If the application only sets "g_width" and "g_height"
        when it sees SDL_VIDEORESIZE, then /not/ sending it can
        cause the application to break because the values are
        never initialized. We don't know how many applications do
        this. If this change was made, then we may find reports
        like "My game crashes in SDL 1.2.16, it has worked for
        years -- this must be a bug in SDL!" So while I agree
        that sending SDL_VIDEORESIZE probably isn't necessary and
        makes your life harder, changing it now will likely do
        more damage.

        Patrick

                 Hum sorry, I didn't understood what you meant in
            your last post ^^'. I'm not a native english speaker,
            doesn't help :p

            _______________________________________________
            SDL mailing list
            SDL at lists.libsdl.org <mailto:SDL at lists.libsdl.org>
            http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org




        _______________________________________________
        SDL mailing list
        SDL at lists.libsdl.org  <mailto:SDL at lists.libsdl.org>
        http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
        ... But that's pointless to have 2 sets of size of the
        same surface and even more weird not to initialize one to
        the other ^^'

        While I perfectly understand that breaking previous
        applications should be avoided as possible, I just checked
        and 1.2.13 didn't do that as well, so only apps made in
        the last 6 months since 1.2.15 are concerned...

        I never looked at the SDL source since today so I could
        try to read it and try to understand why and what has
        changed but I may not be experienced enough to.

        Thanks for your time :)


    If you want to remove this behavior, it seems like it would be
    best to find out why it was added in 1.2.14 in the first
    place. Checking the mercurial history should give some context
    behind it.

    Patrick


    _______________________________________________
    SDL mailing list
    SDL at lists.libsdl.org <mailto:SDL at lists.libsdl.org>
    http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org



_______________________________________________
SDL mailing list
SDL at lists.libsdl.org <mailto:SDL at lists.libsdl.org>
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Aucun virus trouv? dans ce message.
Analyse effectu?e par AVG - www.avg.fr http://www.avg.fr
Version: 2012.0.2197 / Base de donn?es virale: 2437/5139 - Date:
18/07/2012

I don’t get it.

“Note: At the very first call, there will always be an VIDEORESIZE event.”

does this mean it’s supposed to in order to propigate data or whatever or
that it happens and it should not?

if there is a bug and a fix I’d like to make an example for myself that
does one thing with the old lib and something else when compiled with the
new lib.
I’m sorry if that seems a bit thick but it’s the only way I’ll understand
the full extent of this and learning is my drug of choice.On Thu, Jul 19, 2012 at 5:48 AM, D’Archivio Thibault < thibault.darchivio at free.fr> wrote:

Bug reported #1544.
http://bugzilla.libsdl.org/show_bug.cgi?id=1544

The 1.2 / default (2.0/1.3) branches are confusing me, the changeset I
cited was in 2.0

Le 18/07/2012 22:25, Patrick Baggett a ?crit :

D’Archivio,

If you report the bug then I’ll see if I can come up with an appropriate
patch and attached it to bugzilla.

Patrick

On Wed, Jul 18, 2012 at 3:17 PM, Sam Lantinga wrote:

The intent is that you only get the resize event if the window size is
changed outside of SDL_SetVideoMode(). If it’s not working that way, it’s
a bug. I don’t have access to a windows machine at the moment, so patches
(and a bug report in http://bugzilla.libsdl.org) are welcome.

On Mon, Jul 16, 2012 at 5:15 PM, Patrick Baggett < baggett.patrick at gmail.com> wrote:

On Wed, Jul 11, 2012 at 12:46 PM, D’Archivio Thibault < thibault.darchivio at free.fr> wrote:

Le 11/07/2012 19:20, Patrick Baggett a ?crit :

Suppose there is a program “Super Blah Game”, that links to SDL.dll.
You can’t change the code, just SDL.dll

Then, if the game’s code was:

int g_width = -1, g_height = -1;

/* … some menu where user picks screen size … */
int w = userSelectedMode.width;
int h = userSelectedMode.height;

SDL_InitVideo(… SDL_FULLSCREEN … );
SDL_SetVideoMode(…, w, h, … );

/* …Event handling… */
case SDL_VIDEORESIZE:
g_width = event.resize.x;
g_height = event.resize.y;

If the application only sets “g_width” and “g_height” when it sees
SDL_VIDEORESIZE, then not sending it can cause the application to
break because the values are never initialized. We don’t know how many
applications do this. If this change was made, then we may find reports
like “My game crashes in SDL 1.2.16, it has worked for years – this must
be a bug in SDL!” So while I agree that sending SDL_VIDEORESIZE probably
isn’t necessary and makes your life harder, changing it now will likely do
more damage.

Patrick

  Hum sorry, I didn't understood what you meant in your last post

^^’. I’m not a native english speaker, doesn’t help :stuck_out_tongue:


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing listSDL at lists.libsdl.orghttp://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

… But that’s pointless to have 2 sets of size of the same surface
and even more weird not to initialize one to the other ^^’

While I perfectly understand that breaking previous applications should
be avoided as possible, I just checked and 1.2.13 didn’t do that as well,
so only apps made in the last 6 months since 1.2.15 are concerned…

I never looked at the SDL source since today so I could try to read it
and try to understand why and what has changed but I may not be experienced
enough to.

Thanks for your time :slight_smile:

If you want to remove this behavior, it seems like it would be best
to find out why it was added in 1.2.14 in the first place. Checking the
mercurial history should give some context behind it.

Patrick


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing listSDL at lists.libsdl.orghttp://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Aucun virus trouv? dans ce message.
Analyse effectu?e par AVG - www.avg.fr
Version: 2012.0.2197 / Base de donn?es virale: 2437/5139 - Date: 18/07/2012


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Hmm, if I correctly understand your question, for the note I wrote on
first call, I was saying that it should not happens, not that it was a
normal behavior.

I don’t get what you don’t get. I tried to describe the best I could in
bugzilla with my English but maybe it wasn’t clear enough ?
There’s no fix for the moment, and I don’t think I could be able to make
one.

And for an example, the file I attached on bugzilla will show different
results with different version of SDL (1.2.14, 1.2.13, possibly prior
are “correct”, 1.2.15 is “uncorrect”)

Le vendredi 20 juillet 2012 19:27:04, R Manard a ?crit :>

I don’t get it.
“Note: At the very first call, there will always be an VIDEORESIZE event.”

does this mean it’s supposed to in order to propigate data or
whatever or that it happens and it should not?
if there is a bug and a fix I’d like to make an example for myself
that does one thing with the old lib and something else when
compiled with the new lib.
I’m sorry if that seems a bit thick but it’s the only way I’ll
understand the full extent of this and learning is my drug of choice.

On Thu, Jul 19, 2012 at 5:48 AM, D’Archivio Thibault <@Thibault_D_Archivio mailto:Thibault_D_Archivio> wrote:

Bug reported #1544.
http://bugzilla.libsdl.org/show_bug.cgi?id=1544

The 1.2 / default (2.0/1.3) branches are confusing me, the
changeset I cited was in 2.0

Le 18/07/2012 22:25, Patrick Baggett a ?crit :

D’Archivio,

If you report the bug then I’ll see if I can come up with an
appropriate patch and attached it to bugzilla.

Patrick

On Wed, Jul 18, 2012 at 3:17 PM, Sam Lantinga <slouken at libsdl.org <mailto:slouken at libsdl.org>> wrote:

The intent is that you only get the resize event if the
window size is changed outside of SDL_SetVideoMode(). If
it’s not working that way, it’s a bug. I don’t have access
to a windows machine at the moment, so patches (and a bug
report in http://bugzilla.libsdl.org) are welcome.

On Mon, Jul 16, 2012 at 5:15 PM, Patrick Baggett <baggett.patrick at gmail.com <mailto:baggett.patrick at gmail.com>> wrote:

On Wed, Jul 11, 2012 at 12:46 PM, D’Archivio Thibault <@Thibault_D_Archivio mailto:Thibault_D_Archivio> wrote:

Le 11/07/2012 19:20, Patrick Baggett a ?crit :

Suppose there is a program “Super Blah Game”, that
links to SDL.dll. You can’t change the code, just
SDL.dll

Then, if the game’s code was:

int g_width = -1, g_height = -1;

/* … some menu where user picks screen size … */
int w = userSelectedMode.width;
int h = userSelectedMode.height;

SDL_InitVideo(… SDL_FULLSCREEN … );
SDL_SetVideoMode(…, w, h, … );

/* …Event handling… */
case SDL_VIDEORESIZE:
g_width = event.resize.x;
g_height = event.resize.y;

If the application only sets “g_width” and
"g_height" when it sees SDL_VIDEORESIZE, then
/not/ sending it can cause the application to break
because the values are never initialized. We don’t
know how many applications do this. If this change
was made, then we may find reports like “My game
crashes in SDL 1.2.16, it has worked for years –
this must be a bug in SDL!” So while I agree that
sending SDL_VIDEORESIZE probably isn’t necessary and
makes your life harder, changing it now will likely
do more damage.

Patrick

Hum sorry, I didn’t understood what you
meant in your last post ^^’. I’m not a native
english speaker, doesn’t help :stuck_out_tongue:


SDL mailing list
SDL at lists.libsdl.org <mailto:SDL at lists.libsdl.org>
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing list
SDL at lists.libsdl.org <mailto:SDL at lists.libsdl.org>
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

… But that’s pointless to have 2 sets of size of
the same surface and even more weird not to
initialize one to the other ^^’

While I perfectly understand that breaking previous
applications should be avoided as possible, I just
checked and 1.2.13 didn’t do that as well, so only
apps made in the last 6 months since 1.2.15 are
concerned…

I never looked at the SDL source since today so I
could try to read it and try to understand why and
what has changed but I may not be experienced enough to.

Thanks for your time :slight_smile:

If you want to remove this behavior, it seems like it
would be best to find out why it was added in 1.2.14 in
the first place. Checking the mercurial history should
give some context behind it.

Patrick


SDL mailing list
SDL at lists.libsdl.org <mailto:SDL at lists.libsdl.org>
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing list
SDL at lists.libsdl.org <mailto:SDL at lists.libsdl.org>
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing list
SDL at lists.libsdl.org <mailto:SDL at lists.libsdl.org>
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Aucun virus trouv? dans ce message.
Analyse effectu?e par AVG - www.avg.fr http://www.avg.fr
Version: 2012.0.2197 / Base de donn?es virale: 2437/5139 - Date:
18/07/2012


SDL mailing list
SDL at lists.libsdl.org <mailto:SDL at lists.libsdl.org>
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

The way it was worded made it look like you were saying that sam said it
will allways happen period, mean ing no matter what in all versions. Other
stuff too but english is hard i hear, no biggie. So If you tried “it” on 2
versions thats good but that does not prove what happened on other versions
you did not test. I don’t use directx so your example won’t work for me.
I’d be interested to know who changed what and when and what exactly
happens, not just what was observed. I’m not even convinced that sdl has
done anything wrong since it looks like the example checks sdl and not
windows. I’m not saying the message is comming in but I’m just not going to
assume anything. Guess I better make my own example to demostrate.On Fri, Jul 20, 2012 at 2:22 PM, D’Archivio Thibault < thibault.darchivio at free.fr> wrote:

Hmm, if I correctly understand your question, for the note I wrote on
first call, I was saying that it should not happens, not that it was a
normal behavior.

I don’t get what you don’t get. I tried to describe the best I could in
bugzilla with my English but maybe it wasn’t clear enough ?
There’s no fix for the moment, and I don’t think I could be able to make
one.

And for an example, the file I attached on bugzilla will show different
results with different version of SDL (1.2.14, 1.2.13, possibly prior are
"correct", 1.2.15 is “uncorrect”)

Le vendredi 20 juillet 2012 19:27:04, R Manard a ?crit :

I don’t get it.
“Note: At the very first call, there will always be an VIDEORESIZE event.”

does this mean it’s supposed to in order to propigate data or
whatever or that it happens and it should not?
if there is a bug and a fix I’d like to make an example for myself
that does one thing with the old lib and something else when
compiled with the new lib.
I’m sorry if that seems a bit thick but it’s the only way I’ll
understand the full extent of this and learning is my drug of choice.

On Thu, Jul 19, 2012 at 5:48 AM, D’Archivio Thibault <thibault.darchivio at free.fr <mailto:thibault.darchivio@**free.fr<thibault.darchivio at free.fr>>> wrote:

Bug reported #1544.
http://bugzilla.libsdl.org/**show_bug.cgi?id=1544http://bugzilla.libsdl.org/show_bug.cgi?id=1544

The 1.2 / default (2.0/1.3) branches are confusing me, the
changeset I cited was in 2.0

Le 18/07/2012 22:25, Patrick Baggett a ?crit :

D’Archivio,

If you report the bug then I’ll see if I can come up with an
appropriate patch and attached it to bugzilla.

Patrick

On Wed, Jul 18, 2012 at 3:17 PM, Sam Lantinga <slouken at libsdl.org <mailto:slouken at libsdl.org>> wrote:

The intent is that you only get the resize event if the
window size is changed outside of SDL_SetVideoMode(). If
it’s not working that way, it’s a bug. I don’t have access
to a windows machine at the moment, so patches (and a bug
report in http://bugzilla.libsdl.org) are welcome.

On Mon, Jul 16, 2012 at 5:15 PM, Patrick Baggett <baggett.patrick at gmail.com <mailto:baggett.patrick at gmail.**com <baggett.patrick at gmail.com>>> wrote:

On Wed, Jul 11, 2012 at 12:46 PM, D’Archivio Thibault <thibault.darchivio at free.fr <mailto:thibault.darchivio@**free.fr <thibault.darchivio at free.fr>>> wrote:

Le 11/07/2012 19:20, Patrick Baggett a ?crit :

Suppose there is a program “Super Blah Game”, that
links to SDL.dll. You can’t change the code, just
SDL.dll

Then, if the game’s code was:

int g_width = -1, g_height = -1;

/* … some menu where user picks screen size … */
int w = userSelectedMode.width;
int h = userSelectedMode.height;

SDL_InitVideo(… SDL_FULLSCREEN … );
SDL_SetVideoMode(…, w, h, … );

/* …Event handling… */
case SDL_VIDEORESIZE:
g_width = event.resize.x;
g_height = event.resize.y;

If the application only sets “g_width” and
"g_height" when it sees SDL_VIDEORESIZE, then
/not/ sending it can cause the application to break

because the values are never initialized. We don’t
know how many applications do this. If this change
was made, then we may find reports like “My game
crashes in SDL 1.2.16, it has worked for years –
this must be a bug in SDL!” So while I agree that
sending SDL_VIDEORESIZE probably isn’t necessary and
makes your life harder, changing it now will likely
do more damage.

Patrick

Hum sorry, I didn’t understood what you
meant in your last post ^^’. I’m not a native
english speaker, doesn’t help :stuck_out_tongue:

_____________**
SDL mailing list
SDL at lists.libsdl.org <mailto:SDL at lists.libsdl.org>

http://lists.libsdl.org/**listinfo.cgi/sdl-libsdl.orghttp://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

_____________**
SDL mailing list
SDL at lists.libsdl.org <mailto:SDL at lists.libsdl.org>
http://lists.libsdl.org/**listinfo.cgi/sdl-libsdl.orghttp://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

… But that’s pointless to have 2 sets of size of
the same surface and even more weird not to
initialize one to the other ^^’

While I perfectly understand that breaking previous
applications should be avoided as possible, I just
checked and 1.2.13 didn’t do that as well, so only
apps made in the last 6 months since 1.2.15 are
concerned…

I never looked at the SDL source since today so I
could try to read it and try to understand why and
what has changed but I may not be experienced enough to.

Thanks for your time :slight_smile:

If you want to remove this behavior, it seems like it
would be best to find out why it was added in 1.2.14 in
the first place. Checking the mercurial history should
give some context behind it.

Patrick

_____________**
SDL mailing list
SDL at lists.libsdl.org <mailto:SDL at lists.libsdl.org>

http://lists.libsdl.org/**listinfo.cgi/sdl-libsdl.orghttp://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

_____________**
SDL mailing list
SDL at lists.libsdl.org <mailto:SDL at lists.libsdl.org>

http://lists.libsdl.org/**listinfo.cgi/sdl-libsdl.orghttp://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

_____________**
SDL mailing list
SDL at lists.libsdl.org <mailto:SDL at lists.libsdl.org>

http://lists.libsdl.org/**listinfo.cgi/sdl-libsdl.orghttp://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Aucun virus trouv? dans ce message.
Analyse effectu?e par AVG - www.avg.fr http://www.avg.fr

Version: 2012.0.2197 / Base de donn?es virale: 2437/5139 - Date:
18/07/2012

_____________**
SDL mailing list
SDL at lists.libsdl.org <mailto:SDL at lists.libsdl.org>

http://lists.libsdl.org/**listinfo.cgi/sdl-libsdl.orghttp://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

_____________**
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/**listinfo.cgi/sdl-libsdl.orghttp://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

_____________**
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/**listinfo.cgi/sdl-libsdl.orghttp://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

I think everything D’Archivio explained was completely understandable.
Considering the context, there is no room for misinterpretation, either,
given earnest attention. There is a bug report, source code, and previous
discussion of this or similar issues in the past. It sounds like you’re
abusing him slightly, R Manard, so try to revise your replies a little more
carefully, please, in the interest of continued community contributions.

Jonny D

I apologize for not having mentioned the source of confusion. It is the
bugzilla page not any of this email thread. I understand why you would say
this. In the interest of moving forward no abuse was intended, only
explanation of action, as I am doing now. If things like apologizing for
not understanding and stateing of my perspective (what it "seems like"
to me are going to be seen as abuse then I’m not sure how we can
communicate. I’ll try to be more clear. Not being clear is easily done
between people of different native languages so I’ll try to be tolearant
and I hope you will too.On Sat, Jul 21, 2012 at 1:19 PM, Jonathan Dearborn wrote:

I think everything D’Archivio explained was completely understandable.
Considering the context, there is no room for misinterpretation, either,
given earnest attention. There is a bug report, source code, and previous
discussion of this or similar issues in the past. It sounds like you’re
abusing him slightly, R Manard, so try to revise your replies a little more
carefully, please, in the interest of continued community contributions.

Jonny D


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

dangit, wm_size not move but you see where im going. is this a valed proof
of concept?On Sun, Jul 22, 2012 at 5:20 AM, R Manard <@R_Manard> wrote:

Ok, now, I feel like I’m trying to reinvent the wheel to do a windows diag
here to show the messages that are happening. I started from the ground up
and made a regular win32 application:
switch (message)
{
case WM_SIZE:
//xPos = (int)(short) LOWORD(lParam); // horizontal position
//yPos = (int)(short) HIWORD(lParam); // vertical position
sizetrigger=1;
break;
case WM_COMMAND:
wmId = LOWORD(wParam);
wmEvent = HIWORD(wParam);
// Parse the menu selections:
switch (wmId)
{
case IDM_ABOUT:
DialogBox(hInst, (LPCTSTR)IDD_ABOUTBOX, hWnd, (DLGPROC)About);
break;
case IDM_EXIT:
DestroyWindow(hWnd);
break;
default:
return DefWindowProc(hWnd, message, wParam, lParam);
}
break;
case WM_PAINT:
hdc = BeginPaint(hWnd, &ps);
// TODO: Add any drawing code here…
RECT rt;
GetClientRect(hWnd, &rt);
if (sizetrigger) {DrawText(hdc, szMove_message, strlen(szMove_message),
&rt, DT_CENTER);}
else {DrawText(hdc, szHello, strlen(szHello), &rt, DT_CENTER);}
EndPaint(hWnd, &ps);
break;
case WM_DESTROY:
PostQuitMessage(0);
break;
default:
return DefWindowProc(hWnd, message, wParam, lParam);
}

result is “move!” on the screen right when the window comes up. Is this
the kind of demonstration that helps us see when the WM_MOVE message is
recieved or is it flawed in some way or something?

p.s. I changed the .exe to .wtf because gmail would not send it as is

Ok, now, I feel like I’m trying to reinvent the wheel to do a windows diag
here to show the messages that are happening. I started from the ground up
and made a regular win32 application:
switch (message)
{
case WM_SIZE:
//xPos = (int)(short) LOWORD(lParam); // horizontal position
//yPos = (int)(short) HIWORD(lParam); // vertical position
sizetrigger=1;
break;
case WM_COMMAND:
wmId = LOWORD(wParam);
wmEvent = HIWORD(wParam);
// Parse the menu selections:
switch (wmId)
{
case IDM_ABOUT:
DialogBox(hInst, (LPCTSTR)IDD_ABOUTBOX, hWnd, (DLGPROC)About);
break;
case IDM_EXIT:
DestroyWindow(hWnd);
break;
default:
return DefWindowProc(hWnd, message, wParam, lParam);
}
break;
case WM_PAINT:
hdc = BeginPaint(hWnd, &ps);
// TODO: Add any drawing code here…
RECT rt;
GetClientRect(hWnd, &rt);
if (sizetrigger) {DrawText(hdc, szMove_message, strlen(szMove_message),
&rt, DT_CENTER);}
else {DrawText(hdc, szHello, strlen(szHello), &rt, DT_CENTER);}
EndPaint(hWnd, &ps);
break;
case WM_DESTROY:
PostQuitMessage(0);
break;
default:
return DefWindowProc(hWnd, message, wParam, lParam);
}

result is “move!” on the screen right when the window comes up. Is this the
kind of demonstration that helps us see when the WM_MOVE message is
recieved or is it flawed in some way or something?

p.s. I changed the .exe to .wtf because gmail would not send it as is
-------------- next part --------------
A non-text attachment was scrubbed…
Name: message_check.zip
Type: application/zip
Size: 1841377 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20120722/b1f304bb/attachment.zip

R Manard,

No, it is not. Once again, I will refer you to an earlier message that I
wrote:

*Actually, it looks like there is a call to SDL_PrivateResize() inside of
SDL_SetVideoMode() (src/video/SDL_video.c line 687), which creates the
SDL_VIDEORESIZE event. This happens on all platforms. It seems like the
best behavior then is to ignore SDL_VIDEORESIZE events in fullscreen mode,
or at least the first one, since it is artificially generated after OpenGL
context creation (i.e. not in response to a window system / user event). *

In short: The event is not generated due to a Win32 message, it is
generated on all platforms. Please see src/video/SDL_video.c line 687 as I
mentioned or step through it in a debugger and you’ll see what I mean.

I’m working on a potential fix right now.On Sun, Jul 22, 2012 at 5:24 AM, R Manard wrote:

dangit, wm_size not move but you see where im going. is this a valed proof
of concept?

I’ve submitted two patches on Bugzilla that fix this on my machine. I’ve
made them against SDL-1.2 branch of SDL hg. Please test them and tell me if
they fix the issue.

PatrickOn Thu, Jul 19, 2012 at 5:48 AM, D’Archivio Thibault < thibault.darchivio at free.fr> wrote:

Bug reported #1544.
http://bugzilla.libsdl.org/show_bug.cgi?id=1544

The 1.2 / default (2.0/1.3) branches are confusing me, the changeset I
cited was in 2.0

Le 18/07/2012 22:25, Patrick Baggett a ?crit :

D’Archivio,

If you report the bug then I’ll see if I can come up with an appropriate
patch and attached it to bugzilla.

Patrick

On Wed, Jul 18, 2012 at 3:17 PM, Sam Lantinga wrote:

The intent is that you only get the resize event if the window size is
changed outside of SDL_SetVideoMode(). If it’s not working that way, it’s
a bug. I don’t have access to a windows machine at the moment, so patches
(and a bug report in http://bugzilla.libsdl.org) are welcome.

On Mon, Jul 16, 2012 at 5:15 PM, Patrick Baggett < @Patrick_Baggett> wrote:

On Wed, Jul 11, 2012 at 12:46 PM, D’Archivio Thibault < thibault.darchivio at free.fr> wrote:

Le 11/07/2012 19:20, Patrick Baggett a ?crit :

Suppose there is a program “Super Blah Game”, that links to SDL.dll.
You can’t change the code, just SDL.dll

Then, if the game’s code was:

int g_width = -1, g_height = -1;

/* … some menu where user picks screen size … */
int w = userSelectedMode.width;
int h = userSelectedMode.height;

SDL_InitVideo(… SDL_FULLSCREEN … );
SDL_SetVideoMode(…, w, h, … );

/* …Event handling… */
case SDL_VIDEORESIZE:
g_width = event.resize.x;
g_height = event.resize.y;

If the application only sets “g_width” and “g_height” when it sees
SDL_VIDEORESIZE, then not sending it can cause the application to
break because the values are never initialized. We don’t know how many
applications do this. If this change was made, then we may find reports
like “My game crashes in SDL 1.2.16, it has worked for years – this must
be a bug in SDL!” So while I agree that sending SDL_VIDEORESIZE probably
isn’t necessary and makes your life harder, changing it now will likely do
more damage.

Patrick

  Hum sorry, I didn't understood what you meant in your last post

^^’. I’m not a native english speaker, doesn’t help :stuck_out_tongue:


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing listSDL at lists.libsdl.orghttp://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

… But that’s pointless to have 2 sets of size of the same surface
and even more weird not to initialize one to the other ^^’

While I perfectly understand that breaking previous applications should
be avoided as possible, I just checked and 1.2.13 didn’t do that as well,
so only apps made in the last 6 months since 1.2.15 are concerned…

I never looked at the SDL source since today so I could try to read it
and try to understand why and what has changed but I may not be experienced
enough to.

Thanks for your time :slight_smile:

If you want to remove this behavior, it seems like it would be best
to find out why it was added in 1.2.14 in the first place. Checking the
mercurial history should give some context behind it.

Patrick


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing listSDL at lists.libsdl.orghttp://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Aucun virus trouv? dans ce message.
Analyse effectu?e par AVG - www.avg.fr
Version: 2012.0.2197 / Base de donn?es virale: 2437/5139 - Date: 18/07/2012


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Nice 1-letter-patch :slight_smile:
I applied the first patch on latest 1.2 hg and no more resize events
when calling setVideoMode.
However like I think you’ve seen, when the app regain focus, there’s is
an event with the last size.
Then I applied your second patch and those no longer appears.

But, there are still some when minimizing then restoring the app, an
event appears with the last dimensions.
In the second attachment, it seems like you did something related to
minimizing case but in fact there are no changes…

Anyways thanks for the patches :slight_smile:

Le mercredi 25 juillet 2012 21:11:24, Patrick Baggett a ?crit :>

I’ve submitted two patches on Bugzilla that fix this on my machine.
I’ve made them against SDL-1.2 branch of SDL hg. Please test them and
tell me if they fix the issue.

Patrick

On Thu, Jul 19, 2012 at 5:48 AM, D’Archivio Thibault <@Thibault_D_Archivio mailto:Thibault_D_Archivio> wrote:

Bug reported #1544.
http://bugzilla.libsdl.org/show_bug.cgi?id=1544

The 1.2 / default (2.0/1.3) branches are confusing me, the
changeset I cited was in 2.0

Le 18/07/2012 22:25, Patrick Baggett a ?crit :

D’Archivio,

If you report the bug then I’ll see if I can come up with an
appropriate patch and attached it to bugzilla.

Patrick

On Wed, Jul 18, 2012 at 3:17 PM, Sam Lantinga <slouken at libsdl.org <mailto:slouken at libsdl.org>> wrote:

The intent is that you only get the resize event if the
window size is changed outside of SDL_SetVideoMode(). If
it’s not working that way, it’s a bug. I don’t have access
to a windows machine at the moment, so patches (and a bug
report in http://bugzilla.libsdl.org) are welcome.

On Mon, Jul 16, 2012 at 5:15 PM, Patrick Baggett <baggett.patrick at gmail.com <mailto:baggett.patrick at gmail.com>> wrote:

On Wed, Jul 11, 2012 at 12:46 PM, D’Archivio Thibault <@Thibault_D_Archivio mailto:Thibault_D_Archivio> wrote:

Le 11/07/2012 19:20, Patrick Baggett a ?crit :

Suppose there is a program “Super Blah Game”, that
links to SDL.dll. You can’t change the code, just
SDL.dll

Then, if the game’s code was:

int g_width = -1, g_height = -1;

/* … some menu where user picks screen size … */
int w = userSelectedMode.width;
int h = userSelectedMode.height;

SDL_InitVideo(… SDL_FULLSCREEN … );
SDL_SetVideoMode(…, w, h, … );

/* …Event handling… */
case SDL_VIDEORESIZE:
g_width = event.resize.x;
g_height = event.resize.y;

If the application only sets “g_width” and
"g_height" when it sees SDL_VIDEORESIZE, then
/not/ sending it can cause the application to break
because the values are never initialized. We don’t
know how many applications do this. If this change
was made, then we may find reports like “My game
crashes in SDL 1.2.16, it has worked for years –
this must be a bug in SDL!” So while I agree that
sending SDL_VIDEORESIZE probably isn’t necessary and
makes your life harder, changing it now will likely
do more damage.

Patrick

Hum sorry, I didn’t understood what you
meant in your last post ^^’. I’m not a native
english speaker, doesn’t help :stuck_out_tongue:


SDL mailing list
SDL at lists.libsdl.org <mailto:SDL at lists.libsdl.org>
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing list
SDL at lists.libsdl.org <mailto:SDL at lists.libsdl.org>
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

… But that’s pointless to have 2 sets of size of
the same surface and even more weird not to
initialize one to the other ^^’

While I perfectly understand that breaking previous
applications should be avoided as possible, I just
checked and 1.2.13 didn’t do that as well, so only
apps made in the last 6 months since 1.2.15 are
concerned…

I never looked at the SDL source since today so I
could try to read it and try to understand why and
what has changed but I may not be experienced enough to.

Thanks for your time :slight_smile:

If you want to remove this behavior, it seems like it
would be best to find out why it was added in 1.2.14 in
the first place. Checking the mercurial history should
give some context behind it.

Patrick


SDL mailing list
SDL at lists.libsdl.org <mailto:SDL at lists.libsdl.org>
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing list
SDL at lists.libsdl.org <mailto:SDL at lists.libsdl.org>
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing list
SDL at lists.libsdl.org <mailto:SDL at lists.libsdl.org>
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Aucun virus trouv? dans ce message.
Analyse effectu?e par AVG - www.avg.fr http://www.avg.fr
Version: 2012.0.2197 / Base de donn?es virale: 2437/5139 - Date:
18/07/2012


SDL mailing list
SDL at lists.libsdl.org <mailto:SDL at lists.libsdl.org>
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Ok, I get that. A message comes from windows and sdl did not parse it
correctly. It must be hell to compare all of the message all platforms make
and find all of the common ground, and then on top of it make it all make
sense as if one os. I’m not sure I’m saying this right.

is there a master list of all possible messgage all platforms make that sdl
devs have made or do you just add stuff as seems ok as requested? If this
is not topical I can make a topic.On Thu, Jul 26, 2012 at 5:54 AM, D’Archivio Thibault < thibault.darchivio at free.fr> wrote:

Nice 1-letter-patch :slight_smile:
I applied the first patch on latest 1.2 hg and no more resize events when
calling setVideoMode.
However like I think you’ve seen, when the app regain focus, there’s is an
event with the last size.
Then I applied your second patch and those no longer appears.

But, there are still some when minimizing then restoring the app, an event
appears with the last dimensions.
In the second attachment, it seems like you did something related to
minimizing case but in fact there are no changes…

Anyways thanks for the patches :slight_smile:

Le mercredi 25 juillet 2012 21:11:24, Patrick Baggett a ?crit :

I’ve submitted two patches on Bugzilla that fix this on my machine.
I’ve made them against SDL-1.2 branch of SDL hg. Please test them and
tell me if they fix the issue.

Patrick

On Thu, Jul 19, 2012 at 5:48 AM, D’Archivio Thibault <thibault.darchivio at free.fr <mailto:thibault.darchivio@**free.fr<thibault.darchivio at free.fr>>> wrote:

Bug reported #1544.
http://bugzilla.libsdl.org/**show_bug.cgi?id=1544http://bugzilla.libsdl.org/show_bug.cgi?id=1544

The 1.2 / default (2.0/1.3) branches are confusing me, the
changeset I cited was in 2.0

Le 18/07/2012 22:25, Patrick Baggett a ?crit :

D’Archivio,

If you report the bug then I’ll see if I can come up with an
appropriate patch and attached it to bugzilla.

Patrick

On Wed, Jul 18, 2012 at 3:17 PM, Sam Lantinga <slouken at libsdl.org <mailto:slouken at libsdl.org>> wrote:

The intent is that you only get the resize event if the
window size is changed outside of SDL_SetVideoMode(). If
it’s not working that way, it’s a bug. I don’t have access
to a windows machine at the moment, so patches (and a bug
report in http://bugzilla.libsdl.org) are welcome.

On Mon, Jul 16, 2012 at 5:15 PM, Patrick Baggett <baggett.patrick at gmail.com <mailto:baggett.patrick at gmail.**com <baggett.patrick at gmail.com>>> wrote:

On Wed, Jul 11, 2012 at 12:46 PM, D’Archivio Thibault <thibault.darchivio at free.fr <mailto:thibault.darchivio@**free.fr <thibault.darchivio at free.fr>>> wrote:

Le 11/07/2012 19:20, Patrick Baggett a ?crit :

Suppose there is a program “Super Blah Game”, that
links to SDL.dll. You can’t change the code, just
SDL.dll

Then, if the game’s code was:

int g_width = -1, g_height = -1;

/* … some menu where user picks screen size … */
int w = userSelectedMode.width;
int h = userSelectedMode.height;

SDL_InitVideo(… SDL_FULLSCREEN … );
SDL_SetVideoMode(…, w, h, … );

/* …Event handling… */
case SDL_VIDEORESIZE:
g_width = event.resize.x;
g_height = event.resize.y;

If the application only sets “g_width” and
"g_height" when it sees SDL_VIDEORESIZE, then
/not/ sending it can cause the application to break

because the values are never initialized. We don’t
know how many applications do this. If this change
was made, then we may find reports like “My game
crashes in SDL 1.2.16, it has worked for years –
this must be a bug in SDL!” So while I agree that
sending SDL_VIDEORESIZE probably isn’t necessary and
makes your life harder, changing it now will likely
do more damage.

Patrick

Hum sorry, I didn’t understood what you
meant in your last post ^^’. I’m not a native
english speaker, doesn’t help :stuck_out_tongue:

_____________**
SDL mailing list
SDL at lists.libsdl.org <mailto:SDL at lists.libsdl.org>

http://lists.libsdl.org/**listinfo.cgi/sdl-libsdl.orghttp://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

_____________**
SDL mailing list
SDL at lists.libsdl.org <mailto:SDL at lists.libsdl.org>
http://lists.libsdl.org/**listinfo.cgi/sdl-libsdl.orghttp://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

… But that’s pointless to have 2 sets of size of
the same surface and even more weird not to
initialize one to the other ^^’

While I perfectly understand that breaking previous
applications should be avoided as possible, I just
checked and 1.2.13 didn’t do that as well, so only
apps made in the last 6 months since 1.2.15 are
concerned…

I never looked at the SDL source since today so I
could try to read it and try to understand why and
what has changed but I may not be experienced enough to.

Thanks for your time :slight_smile:

If you want to remove this behavior, it seems like it
would be best to find out why it was added in 1.2.14 in
the first place. Checking the mercurial history should
give some context behind it.

Patrick

_____________**
SDL mailing list
SDL at lists.libsdl.org <mailto:SDL at lists.libsdl.org>

http://lists.libsdl.org/**listinfo.cgi/sdl-libsdl.orghttp://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

_____________**
SDL mailing list
SDL at lists.libsdl.org <mailto:SDL at lists.libsdl.org>

http://lists.libsdl.org/**listinfo.cgi/sdl-libsdl.orghttp://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

_____________**
SDL mailing list
SDL at lists.libsdl.org <mailto:SDL at lists.libsdl.org>

http://lists.libsdl.org/**listinfo.cgi/sdl-libsdl.orghttp://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Aucun virus trouv? dans ce message.
Analyse effectu?e par AVG - www.avg.fr http://www.avg.fr

Version: 2012.0.2197 / Base de donn?es virale: 2437/5139 - Date:
18/07/2012

_____________**
SDL mailing list
SDL at lists.libsdl.org <mailto:SDL at lists.libsdl.org>

http://lists.libsdl.org/**listinfo.cgi/sdl-libsdl.orghttp://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

_____________**
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/**listinfo.cgi/sdl-libsdl.orghttp://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

_____________**
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/**listinfo.cgi/sdl-libsdl.orghttp://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Hmm, let me look into that 3rd case there. I guess I didn’t try minimizing
the window…
Yeah, I guess I must have touched that one line, but I didn’t mean to,
that’s for sure – maybe changed whitespace or something.

PatrickOn Thu, Jul 26, 2012 at 5:54 AM, D’Archivio Thibault < thibault.darchivio at free.fr> wrote:

Nice 1-letter-patch :slight_smile:
I applied the first patch on latest 1.2 hg and no more resize events when
calling setVideoMode.
However like I think you’ve seen, when the app regain focus, there’s is an
event with the last size.
Then I applied your second patch and those no longer appears.

But, there are still some when minimizing then restoring the app, an event
appears with the last dimensions.
In the second attachment, it seems like you did something related to
minimizing case but in fact there are no changes…

Anyways thanks for the patches :slight_smile:

Le mercredi 25 juillet 2012 21:11:24, Patrick Baggett a ?crit :

I’ve submitted two patches on Bugzilla that fix this on my machine.
I’ve made them against SDL-1.2 branch of SDL hg. Please test them and
tell me if they fix the issue.

Patrick

On Thu, Jul 19, 2012 at 5:48 AM, D’Archivio Thibault <thibault.darchivio at free.fr <mailto:thibault.darchivio@**free.fr<thibault.darchivio at free.fr>>> wrote:

Bug reported #1544.
http://bugzilla.libsdl.org/**show_bug.cgi?id=1544http://bugzilla.libsdl.org/show_bug.cgi?id=1544

The 1.2 / default (2.0/1.3) branches are confusing me, the
changeset I cited was in 2.0

Le 18/07/2012 22:25, Patrick Baggett a ?crit :

D’Archivio,

If you report the bug then I’ll see if I can come up with an
appropriate patch and attached it to bugzilla.

Patrick

On Wed, Jul 18, 2012 at 3:17 PM, Sam Lantinga <slouken at libsdl.org <mailto:slouken at libsdl.org>> wrote:

The intent is that you only get the resize event if the
window size is changed outside of SDL_SetVideoMode(). If
it’s not working that way, it’s a bug. I don’t have access
to a windows machine at the moment, so patches (and a bug
report in http://bugzilla.libsdl.org) are welcome.

On Mon, Jul 16, 2012 at 5:15 PM, Patrick Baggett <@Patrick_Baggett <mailto:baggett.patrick at gmail.**com <@Patrick_Baggett>>> wrote:

On Wed, Jul 11, 2012 at 12:46 PM, D’Archivio Thibault <thibault.darchivio at free.fr <mailto:thibault.darchivio@**free.fr <thibault.darchivio at free.fr>>> wrote:

Le 11/07/2012 19:20, Patrick Baggett a ?crit :

Suppose there is a program “Super Blah Game”, that
links to SDL.dll. You can’t change the code, just
SDL.dll

Then, if the game’s code was:

int g_width = -1, g_height = -1;

/* … some menu where user picks screen size … */
int w = userSelectedMode.width;
int h = userSelectedMode.height;

SDL_InitVideo(… SDL_FULLSCREEN … );
SDL_SetVideoMode(…, w, h, … );

/* …Event handling… */
case SDL_VIDEORESIZE:
g_width = event.resize.x;
g_height = event.resize.y;

If the application only sets “g_width” and
"g_height" when it sees SDL_VIDEORESIZE, then
/not/ sending it can cause the application to break

because the values are never initialized. We don’t
know how many applications do this. If this change
was made, then we may find reports like “My game
crashes in SDL 1.2.16, it has worked for years –
this must be a bug in SDL!” So while I agree that
sending SDL_VIDEORESIZE probably isn’t necessary and
makes your life harder, changing it now will likely
do more damage.

Patrick

Hum sorry, I didn’t understood what you
meant in your last post ^^’. I’m not a native
english speaker, doesn’t help :stuck_out_tongue:

_____________**
SDL mailing list
SDL at lists.libsdl.org <mailto:SDL at lists.libsdl.org>

http://lists.libsdl.org/**listinfo.cgi/sdl-libsdl.orghttp://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

_____________**
SDL mailing list
SDL at lists.libsdl.org <mailto:SDL at lists.libsdl.org>
http://lists.libsdl.org/**listinfo.cgi/sdl-libsdl.orghttp://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

… But that’s pointless to have 2 sets of size of
the same surface and even more weird not to
initialize one to the other ^^’

While I perfectly understand that breaking previous
applications should be avoided as possible, I just
checked and 1.2.13 didn’t do that as well, so only
apps made in the last 6 months since 1.2.15 are
concerned…

I never looked at the SDL source since today so I
could try to read it and try to understand why and
what has changed but I may not be experienced enough to.

Thanks for your time :slight_smile:

If you want to remove this behavior, it seems like it
would be best to find out why it was added in 1.2.14 in
the first place. Checking the mercurial history should
give some context behind it.

Patrick

_____________**
SDL mailing list
SDL at lists.libsdl.org <mailto:SDL at lists.libsdl.org>

http://lists.libsdl.org/**listinfo.cgi/sdl-libsdl.orghttp://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

_____________**
SDL mailing list
SDL at lists.libsdl.org <mailto:SDL at lists.libsdl.org>

http://lists.libsdl.org/**listinfo.cgi/sdl-libsdl.orghttp://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

_____________**
SDL mailing list
SDL at lists.libsdl.org <mailto:SDL at lists.libsdl.org>

http://lists.libsdl.org/**listinfo.cgi/sdl-libsdl.orghttp://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Aucun virus trouv? dans ce message.
Analyse effectu?e par AVG - www.avg.fr http://www.avg.fr

Version: 2012.0.2197 / Base de donn?es virale: 2437/5139 - Date:
18/07/2012

_____________**
SDL mailing list
SDL at lists.libsdl.org <mailto:SDL at lists.libsdl.org>

http://lists.libsdl.org/**listinfo.cgi/sdl-libsdl.orghttp://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

_____________**
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/**listinfo.cgi/sdl-libsdl.orghttp://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

_____________**
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/**listinfo.cgi/sdl-libsdl.orghttp://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org