Man, you’re quick! Thanks again. Very helpful.
Just one thing I’m still not clear on.
Like I said, they have their own windows message handler. Now, normally
this would be done by getting the next message in the queue (GetMessage,
PeekMessage, whatever). However, they did the following:
- LONG_PTR appWndProc = (LONG_PTR) Application::WindowProc; // our apps
- SetWindowLongPtr(m_hWnd, GWLP_WNDPROC, appWndProc);
Correct me if I’m wrong, but the second line is essentially resetting the
default Window Proc to the apps custom handler. And, as I said before, at
the end of the custom handler it calls the SDL driver window proc. So he
does his custom stuff then uses the SDL driver.
My question is (and I think you’ve already answered it, but I want to be
clear): is all this necessary? I would just use SDL_PollEvent. And it
doesn’t seem like resetting the default window proc is a good idea. (Sorry
if I went off topic a bit…I’m also gonna sk the original authro what’s
“Peter Mulholland” wrote in message
news:163172507.20060424191358 at freeuk.com…> Hello Michael,
Monday, April 24, 2006, 6:24:57 PM, you wrote:
MRB> Some further information…I’m porting a Win32 game to Mac, so that’s
MRB> nature of my questions.
That happens to be my job
MRB> I can’t really share too much of the code because of confidentiality,
MRB> can say that the custom proc is doing the following (this is all
MRB> It checks for the following messages:
MRB> - WM_USER
MRB> - WM_NCLBUTTONDBLCLICK (toggles full screen from windowed mode,
MRB> setting a flag, which is later used by SDL)
MRB> - WM_SYSCOMMAND (again, full screen check using SC_MAXIMIZE param of
MRB> this is using ShowWindow to show the window…it could probably use
MRB> couldn’t it)
MRB> - WM_SIZE (sizing again), and WM_ACTIVATEAPP (upon activation). Both
MRB> using SDL.
MRB> - It also checks for a custom message (having to do with only
MRB> instance of the app).
MRB> After this, the main handler calls another function which checks the
MRB> following messages:
MRB> - WM_ACTIVEATE (calling ShowWindow…you make a good point about SDL
MRB> probably being able to handle this stuff…I’m not sure why they’re
MRB> custom via Windows)
MRB> - WM_SIZE (saving old window settings)
I see absolutely no reason why the original author couldn’t have used
SDL for all of that, except perhaps the instance check (there’s other
ways to do that though).
You get notified of resize events with the SDL_VIDEORESIZE event. You
get the hide/show info with SDL_ACTIVEEVENT. The handling of
WM_NCLBUTTONDBLCLICK (which would happen if the user double clicked in
the window’s title bar) and WM_SYSCOMMAND indicates they wanted to add
Maximise support. Perhaps they wrote the game with an earlier SDL that
didn’t support it. It certainly does support resizable windows now.
MRB> So, what exactly does the SDL driver proc do?
Handles all the message events to do with the window. If you want to
see it, look at wincommon/SDL_sysevents.c and either
windx5/SDL_dx5events.c or windib/SDL_dibevents.c
MRB> Also, regarding Mac equivalent…how do I get the handle to the Mac
MRB> SDL driver proc?
Briefly looking at SDL_syswm.h - you can’t.
Messing with the window proc is a bad idea anyway. There is almost no
need to do it. I’ve only used the syswm stuff once and that was a
quick hack to get a sound driver that wanted the Window handle.
Peter mailto:darkmatter at freeuk.com