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
message handler
- 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
going on).
Thanks,
Ryan
“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
the
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,
but I
MRB> can say that the custom proc is doing the following (this is all
Win32):
MRB> It checks for the following messages:
MRB> - WM_USER
MRB> - WM_NCLBUTTONDBLCLICK (toggles full screen from windowed mode,
simply
MRB> setting a flag, which is later used by SDL)
MRB> - WM_SYSCOMMAND (again, full screen check using SC_MAXIMIZE param of
msg;
MRB> this is using ShowWindow to show the window…it could probably use
SDL,
MRB> couldn’t it)
MRB> - WM_SIZE (sizing again), and WM_ACTIVATEAPP (upon activation). Both
end up
MRB> using SDL.
MRB> - It also checks for a custom message (having to do with only
allowing one
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
doing it
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.
–
Best regards,
Peter mailto:darkmatter at freeuk.com