SDLNet IPv4 to numerical addresses

Ok. Sorry for all the trouble. I have found a sollution now that makes me
able to use the dialog boxes. However. I do not understand why it works with
this “fix”

If i include commctrl.h AND call InitCommonControls ANYWHERE it works.
The weird part is that i can call InitCommonControls after the whole game
engine is shutdown.

So calling that function doesnt seem to be as important as just having it
linked into the exe.

Just out of curiosity it would be fun if anyone could explain why it starts
to work by just having it anywhere in the code without actually calling it
before creating the DialogBox.

Happy thing is that I can now continue on solving some real problems without
having to worry about having to switch away from SDL.

// Tomaz

----Original Message Follows----From: john@johnnypops.demon.co.uk (John Popplewell)
Reply-To: “A list for developers using the SDL library.
(includesSDL-announce)”
To: "A list for developers using the SDL library. (includes
SDL-announce)"
Subject: Re: [SDL] Dialog boxes.
Date: Mon, 13 Mar 2006 22:33:01 +0000

On Mon, Mar 13, 2006 at 09:22:00PM +0100, Tomas Jakobsson wrote:

This is the code i use in the regular win32 code:

while (PeekMessage (&Message, NULL, 0, 0, PM_REMOVE))
{
TranslateMessage (&Message);
DispatchMessage (&Message);

if (Message.message == WM_QUIT)
    pBase->Quit = TRUE;

}

and this is the code i use in the SDL code:

while (SDL_PollEvent (&Event))
{
… lots and lots of code to grab input and other stuff
}

Which is run each frame.
I just did a test and ran both the SDL_PollEvents loop AND the plain
win32
PeekMessage thing right before creating my DialogBox just to be sure that
all messages are flushed out and it still wont show up.
A simple MessageBox works just fine tho.

MessageBox (NULL, “Test”, “Test”, MB_OK);

// Tomaz

Tomaz,

the attached code displays an OpenGL/SDL window and a modeless dialog.
I’m using the current CVS version of SDL. Works OK here.

Please show us a small, complete example that exhibits the problem,

best regards,
John.

<< resource.h >>

<< modeless.rc >>

<< modeless.c >>


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

Hello Tomas,

Monday, March 13, 2006, 11:32:33 PM, you wrote:

TJ> Ok. Sorry for all the trouble. I have found a sollution now that makes me
TJ> able to use the dialog boxes. However. I do not understand why it works with
TJ> this “fix”

TJ> If i include commctrl.h AND call InitCommonControls ANYWHERE it works.
TJ> The weird part is that i can call InitCommonControls after the whole game
TJ> engine is shutdown.

TJ> So calling that function doesnt seem to be as important as just having it
TJ> linked into the exe.

TJ> Just out of curiosity it would be fun if anyone could explain why it starts
TJ> to work by just having it anywhere in the code without actually calling it
TJ> before creating the DialogBox.

TJ> Happy thing is that I can now continue on solving some real problems without
TJ> having to worry about having to switch away from SDL.

Oh! Were you using some advanced controls in your dialog, like rebars
and such?

These always need this function to be called. I have no idea why it
worked on your basic code. I got this problem many years ago when I
first started writing windows apps :)–
Best regards,
Peter mailto:@Peter_Mulholland

Yeah. I kinda knew it as well. Still… The scary part is why the dialogbox
works even when I call InitCommonControls AFTER creating the dialogbox.

// Tomaz

----Original Message Follows----From: darkmatter@freeuk.com (Peter Mulholland)
Reply-To: Peter Mulholland ,“A list for developers
using the SDL library. (includesSDL-announce)”
To: "A list for developers using the SDL library. (includes
SDL-announce)"
Subject: Re: [SDL] Dialog boxes.
Date: Mon, 13 Mar 2006 23:34:38 +0000

Hello Tomas,

Monday, March 13, 2006, 11:32:33 PM, you wrote:

TJ> Ok. Sorry for all the trouble. I have found a sollution now that makes
me
TJ> able to use the dialog boxes. However. I do not understand why it works
with
TJ> this “fix”

TJ> If i include commctrl.h AND call InitCommonControls ANYWHERE it works.
TJ> The weird part is that i can call InitCommonControls after the whole
game
TJ> engine is shutdown.

TJ> So calling that function doesnt seem to be as important as just having
it
TJ> linked into the exe.

TJ> Just out of curiosity it would be fun if anyone could explain why it
starts
TJ> to work by just having it anywhere in the code without actually calling
it
TJ> before creating the DialogBox.

TJ> Happy thing is that I can now continue on solving some real problems
without
TJ> having to worry about having to switch away from SDL.

Oh! Were you using some advanced controls in your dialog, like rebars
and such?

These always need this function to be called. I have no idea why it
worked on your basic code. I got this problem many years ago when I
first started writing windows apps :slight_smile:


Best regards,
Peter mailto:darkmatter at freeuk.com


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

Hello Tomas,

Monday, March 13, 2006, 11:39:09 PM, you wrote:

TJ> Yeah. I kinda knew it as well. Still… The scary part is why the dialogbox
TJ> works even when I call InitCommonControls AFTER creating the dialogbox.

The dialog box is not actually opened until your program starts
pumping the message loop. As long as it is called before the message
loop starts and the WM_INITDIALOG message is recieved, it works.–
Best regards,
Peter mailto:@Peter_Mulholland

----Original Message Follows----From: darkmatter@freeuk.com (Peter Mulholland)
Reply-To: Peter Mulholland ,“A list for developers
using the SDL library. (includesSDL-announce)”
To: "A list for developers using the SDL library. (includes
SDL-announce)"
Subject: Re: [SDL] Dialog boxes.
Date: Mon, 13 Mar 2006 23:50:31 +0000

Hello Tomas,

Monday, March 13, 2006, 11:39:09 PM, you wrote:

TJ> Yeah. I kinda knew it as well. Still… The scary part is why the
dialogbox
TJ> works even when I call InitCommonControls AFTER creating the dialogbox.

The dialog box is not actually opened until your program starts
pumping the message loop. As long as it is called before the message
loop starts and the WM_INITDIALOG message is recieved, it works.


Best regards,
Peter mailto:darkmatter at freeuk.com


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

Wil do. And thanks alot for all the help!

// Tomaz

----Original Message Follows----From: darkmatter@freeuk.com (Peter Mulholland)
Reply-To: Peter Mulholland
To: “Tomas Jakobsson” <@Tomas_Jakobsson>
Subject: Re[2]: [SDL] Dialog boxes.
Date: Tue, 14 Mar 2006 00:09:11 +0000

Hello Tomas,

Monday, March 13, 2006, 11:55:53 PM, you wrote:

TJ> But it isnt called before the message pumping starts. It isnt called
until
TJ> after the entire game engine is shutdown. As a test i put it in main ()
TJ> right before the return (0); at the end. It still works. If I remove it
tho
TJ> it stops working again.

Hmm, my second guess is now that this causes commctl32.dll to be
linked to your game. You used to have to call InitCommonControls()
before you did ANYTHING. My guess is that they have now moved this
into the DllMain() so that as soon as your app loads up, the
InitCommonControls() stuff is actually done. The reason you still need
the function call, is because if you don’t put it, Visual C++ or
whatever sees that you used no symbols from that DLL, and doesn’t make
your app link to it.

I would not rely on this - it might be a recent thing that Microsoft
have added. Stick with the InitCommonControls() call right before you
start doing anything with dialogs.


Best regards,
Peter mailto:darkmatter at freeuk.com

Is there any good reason NOT to just use this existing DC?

Yes, with some drivers, once you set an OpenGL context on a window,
you can’t change certain basic attributes of it.

-Sam Lantinga, Senior Software Engineer, Blizzard Entertainment

By the way, (some of) this issue has been added to bugzilla:
https://bugzilla.libsdl.org/show_bug.cgi?id=162

See ya!
-Sam Lantinga, Senior Software Engineer, Blizzard Entertainment

Hi,

to summarise: the rest of this thread turned out to be a problem
unrelated to SDL.

However, I’ve now tested the patch for the assert() / MessageBox()
OpenGL bug on:

Win98SE with Nvidia TNT2
Win2K SP4 with Intel 855 and Nvidia GeForce-2
WinXP SP2 (no .NET) with ATI Radeon 9600

using SDL CVS, and MSYS/MinGW build tools.

The test program is 100% reproducible for me (the second dialog isn’t
displayed), on all systems, and the problem is fixed by the patch.

I can supply binaries if anyone is interested,

cheers,
John.On Mon, Mar 13, 2006 at 03:31:51PM +0000, John Popplewell wrote:

On Sun, Mar 12, 2006 at 05:54:28PM -0800, Sam Lantinga wrote:

This might be a silly question but here it goes.

After using SDL with OpenGL for several years with win32 as my main
plattform I now decided to save some time and not code an OpenGL GUI but use
a simple win32 dialog box to make some kind of gui.

But to my surprise it didnt seem to be possible to create dialog boxes when
using SDL.
I did a quick test and removed the SDL window init code and made a regular
win32 window and then the dialog box creation worked.

This is a bug, which has been reported but nobody has figured out why
it doesn’t work. Please post if you figure it out!

-Sam Lantinga, Senior Software Engineer, Blizzard Entertainment

Hello John,

Tuesday, March 14, 2006, 12:29:28 AM, you wrote:

JP> to summarise: the rest of this thread turned out to be a problem
JP> unrelated to SDL.

Indeed :slight_smile:

JP> However, I’ve now tested the patch for the assert() / MessageBox()
JP> OpenGL bug on:

JP> Win98SE with Nvidia TNT2
JP> Win2K SP4 with Intel 855 and Nvidia GeForce-2
JP> WinXP SP2 (no .NET) with ATI Radeon 9600

JP> using SDL CVS, and MSYS/MinGW build tools.

JP> The test program is 100% reproducible for me (the second dialog isn’t
JP> displayed), on all systems, and the problem is fixed by the patch.

JP> I can supply binaries if anyone is interested,

Please send, if they have debug symbols. I will trace this.

I had no problems with assert in GL mode but I was using MSVC.NET 2003
compiler and not mingw. Maybe this is some bug in the older msvcrt.dll
which mingw uses but MSVC.NET does not.–
Best regards,
Peter mailto:@Peter_Mulholland

Oh. That’s the end of that then :-)On Mon, Mar 13, 2006 at 04:13:15PM -0800, Sam Lantinga wrote:

Is there any good reason NOT to just use this existing DC?

Yes, with some drivers, once you set an OpenGL context on a window,
you can’t change certain basic attributes of it.

Hello John,

Tuesday, March 14, 2006, 12:29:28 AM, you wrote:

JP> to summarise: the rest of this thread turned out to be a problem
JP> unrelated to SDL.

Indeed :slight_smile:

JP> However, I’ve now tested the patch for the assert() / MessageBox()
JP> OpenGL bug on:

JP> Win98SE with Nvidia TNT2
JP> Win2K SP4 with Intel 855 and Nvidia GeForce-2
JP> WinXP SP2 (no .NET) with ATI Radeon 9600

JP> using SDL CVS, and MSYS/MinGW build tools.

JP> The test program is 100% reproducible for me (the second dialog isn’t
JP> displayed), on all systems, and the problem is fixed by the patch.

JP> I can supply binaries if anyone is interested,

Please send, if they have debug symbols. I will trace this.
Peter,

I have made some that do, but I suspect you’ll need GDB to step through
them. Also, they are massive :slight_smile:

Here is a 1.8M ZIP archive with the msgbox.exe test program and two
copies of SDL.dll with symbols:

http://johnnypops.demon.co.uk/files/msgbox.zip

SDL-good.dll is the one with the patch that fixes the problem for me, but
Sam has pointed out that it won’t work for some drivers and can’t be
used :frowning:

I had no problems with assert in GL mode but I was using MSVC.NET 2003
compiler and not mingw. Maybe this is some bug in the older msvcrt.dll
which mingw uses but MSVC.NET does not.

That’s an interesting possibility.

Sam has pointed this out:

https://bugzilla.libsdl.org/show_bug.cgi?id=162

See you there, let me know how you get on,

regards,
John.On Tue, Mar 14, 2006 at 12:33:45AM +0000, Peter Mulholland wrote:


Best regards,
Peter mailto:darkmatter at freeuk.com


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

Hello !

Here is a 1.8M ZIP archive with the msgbox.exe test program and two
copies of SDL.dll with symbols:

http://johnnypops.demon.co.uk/files/msgbox.zip

I tested this too and get a failed
message when using both DLLs.

CU

Hi John,

Out of curiousity, where or how from this code is the message injection
occuring?

Are you saying that since SDL_Appname Is NULL, so a NULL window class. I’m
not even sure what that means. I think 0 may be the class name for a dialog
box. So MessageBox then would use the same class name as this invisible
window, now bounded to the OpenGL context. Perhaps the fact that more than
one instance of a window class is trying to share a context in OpenGL makes
it unhappy. So perhaps the driver decides to post a destroy message. The
next time a window is created with that class name, it is there waiting in
the queue.

Is this what you mean?

MatthewOn Sun, Mar 12, 2006 at 05:54:28PM -0800, Sam Lantinga wrote:

This might be a silly question but here it goes.

After using SDL with OpenGL for several years with win32 as my main
plattform I now decided to save some time and not code an OpenGL GUI
but use

a simple win32 dialog box to make some kind of gui.

But to my surprise it didnt seem to be possible to create dialog boxes
when

using SDL.
I did a quick test and removed the SDL window init code and made a
regular

win32 window and then the dialog box creation worked.

This is a bug, which has been reported but nobody has figured out why
it doesn’t work. Please post if you figure it out!

  -Sam Lantinga, Senior Software Engineer, Blizzard Entertainment

Hi,

I’ve had a look at it and it is caused by the creation of a temporary
window in Init_WGL_ARB_extensions() in SDL_wingl.c which injects some
messages into the application message queue.

I tried a few things, like changing:

hwnd = CreateWindow(SDL_Appname, SDL_Appname, WS_POPUP|WS_DISABLED, …

into:

hwnd = CreateWindow(“STATIC”, NULL, WS_POPUP|WS_DISABLED, …

but I’m not confident that a static text control window will always be
happy having an OpenGL context attached to it :o) so I also tried a call
to FlushMessageQueue() after the DestroyWindow() call at the end of
Init_WGL_ARB_extensions().

They both worked, but I finally settled on using the existing device
context, GL_hdc, and just removing the window and dc creation /
destruction functionsr: see the attached patch.

Is there any good reason NOT to just use this existing DC?

I’ve attached a test program that reproduces the problem and allowed me
to determine that it happens with both windib and directx drivers and
doesn’t happen unless OpenGL is enabled.

A quick comment/compile/test binary search through the source led me to
Init_WGL_ARB_extensions(),

cheers,
John Popplewell.


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

Matt Johnson
Graphics Developer
VCom3D, Inc.

As a followup, if you look at the definition of DLGTEMPLATE, you get this:
"Following the menu array is a class array that identifies the window class
of the control. If the first element of the array is 0x0000, the system uses
the predefined dialog box class for the dialog box and the array has no
other elements. If the first element is 0xFFFF, the array has one additional
element that specifies the ordinal value of a predefined system window
class. If the first element has any other value, the system treats the array
as a null-terminated Unicode string that specifies the name of a registered
window class. "

Seems to follow my thinking. I don’t think the (SDL) code does the
injection. DestroyWindow/CreateWindow calls the win proc. The injection must
come from elsewhere :stuck_out_tongue:

MattOn 3/13/06, Matt J <@Matt_J> wrote:

Hi John,

Out of curiousity, where or how from this code is the message injection
occuring?

Are you saying that since SDL_Appname Is NULL, so a NULL window class. I’m
not even sure what that means. I think 0 may be the class name for a dialog
box. So MessageBox then would use the same class name as this invisible
window, now bounded to the OpenGL context. Perhaps the fact that more than
one instance of a window class is trying to share a context in OpenGL makes
it unhappy. So perhaps the driver decides to post a destroy message. The
next time a window is created with that class name, it is there waiting in
the queue.

Is this what you mean?

Matthew

On Sun, Mar 12, 2006 at 05:54:28PM -0800, Sam Lantinga wrote:

This might be a silly question but here it goes.

After using SDL with OpenGL for several years with win32 as my main
plattform I now decided to save some time and not code an OpenGL GUI
but use

a simple win32 dialog box to make some kind of gui.

But to my surprise it didnt seem to be possible to create dialog boxes
when

using SDL.
I did a quick test and removed the SDL window init code and made a
regular

win32 window and then the dialog box creation worked.

This is a bug, which has been reported but nobody has figured out why
it doesn’t work. Please post if you figure it out!

  -Sam Lantinga, Senior Software Engineer, Blizzard Entertainment

Hi,

I’ve had a look at it and it is caused by the creation of a temporary
window in Init_WGL_ARB_extensions() in SDL_wingl.c which injects some
messages into the application message queue.

Out of curiousity, where or how from this code is the message injection
occuring?

Hi Matthew,

I think this is academic now but anyway.

Are you saying that since SDL_Appname Is NULL, so a NULL window class.

RE: the code below:

hwnd = CreateWindow(SDL_Appname, SDL_Appname, WS_POPUP|WS_DISABLED, …

SDL_Appname isn’t NULL, it is set to “SDL_app” and is the registered
classname, which means it shares a window procedure and message queue
(belonging to the main thread) with the rest of SDL (I think!).

Calls to CreateWindow() / DestroyWindow() send messages (meaning
immediately calls into) the windows procedure. DestroyWindow() calls the
WM_DESTROY handler which usually posts (meaning puts into the message
queue for when a message-loop is eventually run) a WM_QUIT message which
causes the next message-loop to be run to immediately exit. Well, that’s
my take on it anyway.

I came across this a few years back in a non-SDL windows app. using
full-screen DX. After tearing my hair out for a couple of days, I
accidentally had the sound switched on and heard the beep from the
missing message-box :slight_smile:

After that, it didn’t take me long to come up with the evil
FlushMessageQueue() hack :slight_smile:

For a laugh, here is my posting to this list when the problem turned up
again:

http://www.libsdl.org/pipermail/sdl/2002-May/045280.html

Looks like Sam put it in SDL itself shortly after this,

regards,
John.

I’m not even sure what that means. I think 0 may be the class name for a dialog
box. So MessageBox then would use the same class name as this invisible
window, now bounded to the OpenGL context. Perhaps the fact that more than
one instance of a window class is trying to share a context in OpenGL makes
it unhappy. So perhaps the driver decides to post a destroy message. The
next time a window is created with that class name, it is there waiting in
the queue.

Is this what you mean?

Matthew

<snip!>On Mon, Mar 13, 2006 at 09:13:47PM -0500, Matt J wrote:

Hmm. When I searched the code of 1.2.9, SDL_AppName was set to NULL. I
realize its academic, well, a fix is a fix. As a programmer, bugs gravitate
to me. I seem to crash software by my mere presense, so I’m pretty paranoid
programmer :slight_smile: I once solved a bug in our software caused by the COM
threading context that java threads in a JVM had to enter to. Sometimes when
doing windows programming you have to ponder how Microsoft implements things
behind the scenes, so you don’t do something stupid and fool yourself into
believing you understand the cause of the problem. I just imagine a purely
evil implementation, and that usually is on the mark.

Honestly, I’ve been on a bit of a Warcraft III binge lately. Hard to
contribute to code when Blizzard makes these addicting games. Sigh.

Matt

Out of curiousity, where or how from this code is the message injection
occuring?

Hi Matthew,

I think this is academic now but anyway.

Are you saying that since SDL_Appname Is NULL, so a NULL window class.

RE: the code below:

hwnd = CreateWindow(SDL_Appname, SDL_Appname, WS_POPUP|WS_DISABLED, …

SDL_Appname isn’t NULL, it is set to “SDL_app” and is the registered
classname, which means it shares a window procedure and message queue
(belonging to the main thread) with the rest of SDL (I think!).

Calls to CreateWindow() / DestroyWindow() send messages (meaning
immediately calls into) the windows procedure. DestroyWindow() calls the
WM_DESTROY handler which usually posts (meaning puts into the message
queue for when a message-loop is eventually run) a WM_QUIT message which
causes the next message-loop to be run to immediately exit. Well, that’s
my take on it anyway.

Hmm. When I searched the code of 1.2.9, SDL_AppName was set to NULL.
It is initially, but gets set at about line 772 in
wincommon/SDL_sysevent.c just before the WNDCLASS struct is filled-out.

The explanation I put forward just seems likely to me, it isn’t
neccessarily correct. I think I tried to find experimental evidence for
it years ago and came up blank. FlushMessageQueue() certainly comes up
with a WM_QUIT message from somewhere though (if you try printing them
out).

I realize its academic, well, a fix is a fix. As a programmer, bugs gravitate
to me. I seem to crash software by my mere presense, so I’m pretty paranoid
programmer :slight_smile:
Tell me about it :slight_smile: I stay away from live performance (something my
brothers are involved in) because getting to the root-cause of the
problem 10 minutes before the gig just isn’t important.

I once solved a bug in our software caused by the COM threading
context that java threads in a JVM had to enter to. Sometimes when
doing windows programming you have to ponder how Microsoft implements
things behind the scenes, so you don’t do something stupid and fool
yourself into believing you understand the cause of the problem. I
just imagine a purely evil implementation, and that usually is on the
mark.

Hehe. Bugs in threaded software: lots of them, but difficult to reproduce.

Honestly, I’ve been on a bit of a Warcraft III binge lately. Hard to
contribute to code when Blizzard makes these addicting games. Sigh.

Cold showers and brisk walks :slight_smile:

cheers,
John.On Tue, Mar 14, 2006 at 10:36:23AM -0500, Matt J wrote:

Matt

Out of curiousity, where or how from this code is the message injection
occuring?

Hi Matthew,

I think this is academic now but anyway.

Are you saying that since SDL_Appname Is NULL, so a NULL window class.

RE: the code below:

hwnd = CreateWindow(SDL_Appname, SDL_Appname, WS_POPUP|WS_DISABLED, …

SDL_Appname isn’t NULL, it is set to “SDL_app” and is the registered
classname, which means it shares a window procedure and message queue
(belonging to the main thread) with the rest of SDL (I think!).

Calls to CreateWindow() / DestroyWindow() send messages (meaning
immediately calls into) the windows procedure. DestroyWindow() calls the
WM_DESTROY handler which usually posts (meaning puts into the message
queue for when a message-loop is eventually run) a WM_QUIT message which
causes the next message-loop to be run to immediately exit. Well, that’s
my take on it anyway.


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

Hello John,

Tuesday, March 14, 2006, 4:33:04 PM, you wrote:

JP> The explanation I put forward just seems likely to me, it isn’t
JP> neccessarily correct. I think I tried to find experimental evidence for
JP> it years ago and came up blank. FlushMessageQueue() certainly comes up
JP> with a WM_QUIT message from somewhere though (if you try printing them
JP> out).

It was broken all along. I’m actually quite surprised it worked at all
up until now. Windows apps rely on the message loop when you do things
with windows, the messages have to flow or nothing works.–
Best regards,
Peter mailto:@Peter_Mulholland

Hi John, everything you say is accurate. If a dialog does receive a WM_QUIT
message, it posts it to the main window, according to the Win32
documentation. It makes sense that the dialog message loop will exit, but
why isn’t the main program exiting?

Maybe this phantom WM_QUIT, that is always in the loop as you say, so they
simply filter it out in the main message loop? I have to look at the SDL
code when I get home.

Matthew> SDL_Appname isn’t NULL, it is set to “SDL_app” and is the registered

classname, which means it shares a window procedure and message queue
(belonging to the main thread) with the rest of SDL (I think!).

Calls to CreateWindow() / DestroyWindow() send messages (meaning
immediately calls into) the windows procedure. DestroyWindow() calls the
WM_DESTROY handler which usually posts (meaning puts into the message
queue for when a message-loop is eventually run) a WM_QUIT message which
causes the next message-loop to be run to immediately exit. Well, that’s
my take on it anyway.