error on exit

You do not really need to assign NULL to the LPDIRECTDRAW object after it has been released.... but it should not be the cause of the crashing. I have been racking my brain with DirectDraw functions for awhile.

Good luck

I had the same problem with DD5. If you release the direct draw object before the surfaces, it will crash big time. Make sure to free your surfaces before your direct draw object.
Hope that helps

quote:

---

Original post by Gaiiden

My program causes an illegal operation error after it closes. I did a bit of debugging and I realized that it was the code segment that released the main surface:

if (lpdds7)
{
lpdds7->Release();
lpdds7 = NULL;
}

---

I was having the same problem just yesterday, but with releasing my back buffer. If you''re using D3D, be sure to release the D3DDevice before you release the DD surfaces. If not, I have no idea^^

---

-Deku-chan

DK Art (my site, which has little programming-related stuff on it, but you should go anyway^_^)

"I'm dropping like flies!" - me, playing Super Smash Bros. (and losing)
"What fun!" - me, playing Super Smash Bros. (and beating the crap out of somebody)

OK, lemme clarify.

1 - setting it to NULL is just a precautionary measure
2 - I said towards the end of my post that I released my DD
objects in reverse order of creation
3 - I am using DirectDraw and I have no backbuffer, just a
primary surface

I still haven''t figured out what''s wrong with my program. Thanks for trying, guys, but you didn''t read well enough. any one else??

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

And mine was pointless anyway, cause I was just working on my program again and passed by that code, discovering that I just commented out the lpDDSBack->Release() part, cause it didn't work even with the 3DDevice released^_^ Then I noticed that my problem was I released the primary surface first, so yours must be having some other problem. The only thing I can think of is did you release lpDD before the surface? I'm sure you didn't, but I'd have to mess with it for a while to figure anything else out.

---

-Deku-chan

DK Art (my site, which has little programming-related stuff on it, but you should go anyway^_^)

"I'm dropping like flies!" - me, playing Super Smash Bros. (and losing)
"What fun!" - me, playing Super Smash Bros. (and beating the crap out of somebody)

Edited by - DekuTree64 on October 4, 2000 4:05:22 PM

Are u mult threaded?

if u are u should release the objects in the same thread that created them....

also another thread can eventually do some ddraw/d3d actions after or in the same time with release()...
so stop all working/flipping threads first

also check your WM_ActivateApp or WM_Close message handlers...they will be called in the shutdown process of your application....maybe u do some stuff there....but DDraw objects are not anymore?

Hope to help

Bogdan

Question: What are you doing before releasing the surface pointer?

I only ask because the problem might be related to whatever
you are releasing before it. Check to make sure you are not
releasing the DirectDraw object before the surfaces because
this will cause the said problem.

Maybe you''ve already tried it but the list for releasing
should be:

Vid/System memory surfaces (not primary/back/z)
Direct3D device (if applicable)
Direct3D
Z buffer
Back buffer
Primary
DirectDraw.

--
Code..reboot..code..reboot..sigh!

what version of MSVC are you using?
i know there was a bug with some versions that would mean you would have to write it like:

if(lpdds7 != NULL)
...

try that (im not saying it will work, just an idea..)

I''ll say again that I always release DD objects in reverse order of creation, meaning I''ll always release the main DD object last. No, I''m not using threads. Before releasing I''m not doing anything. I release first then carry out other shutdown stuff (not DD related). I close my program by posting a WM_DESTROY message. In the message handler I release the objects and post a quit message to end the app. Is that a problem?? I detect a keypress with a WM_KEYDOWN message (I sometimes use Andre LaMothes KEYUP and KEYDOWN macros too). Before the keypress is processed I''m locking the primary surface, writing a random pixel, and unlocking the surface. I''m using VC++ 4 Standard Edition.

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

quote:

---

Original post by Gaiiden
I'm using VC++ 4 Standard Edition.

---

did you even read my previous post?


Edited by - Quantum on October 6, 2000 8:03:33 AM

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.

yeah but the VC6 on TOTWGPG is only the introductory version

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.
==============================