Yeah, Quantum, I did, but I''m replying to all these things at school every morning so i can''t try them right away, and I forgot to do it last night, so I still don''t know if it works, sorry. I''ll try it out tonight, thanks.


==============================
\\// live long and prosper; \||/ die short and rot.
==============================

You do know that VC6 is on one of the CDs that come with TOTWGPG...

Does the illegal op come when you call ->Release or does it just go away if you comment the release out?

If it goes away if you comment it out, you are probably trying to render to it after you released it. "Out of execution order" bug i bet.

Sorry, Quantum, your suggestion didn''t help. And I don;t think it could be order of execution. Well, maybe. Here''s the deal: I have a game loop (straight from TOTWGPG) that writes a random pixel to the surface (just one surface) every iteration. Now, the program uses the WM_KEYDOWN message to detect the escape key being pressed. When that happens, the WM_KEYDOWN message handler posts (not sends) a WM_DESTROY message. In that message handler all the objects are released and a WM_QUIT message is posted. Going back over that order of operation, could the loop iterate once more in between the post of the WM_DESTROY or the WM_QUIT messages? Should I send messages rather than post them? I''ll try puuting a "gate" at the beginning of the game loop to test to see if a flag saying the surface has been released is set, and it will skip the pixel plotting. We''ll see if that works, in the mean time, any more ideas?

==============================
\\// live long and prosper; \||/ die short and rot.
==============================

OK, I got it. Turns out the game loop was iterating again after I released the main surface. D''oh! So i just made a global variable that breaks the loop after the WM_DESTROY message has been received. Case closed.

==============================
\\// live long and prosper; \||/ die short and rot.
==============================