If you've Locked() a directdraw surface forget about interactive debugging until you've Unlocked() it. Same for GetDC() / ReleaseDC(), as GetDC() calls Lock() internally.

Note, however, that even tho your display is locked, everything else is functioning beneath the surface... if your machine *appears* to be hung, usually it's because something has triggered VC's debugger, and VC has popped up a message box. Try hitting the space bar (equiv. to clicking "OK" on the msgbox), then hitting Alt+F5 (or whatever your "Stop Debugging" key is). If this doesn't work, try hitting Alt+F4.. it'll close VC, but it's better than rebooting each time.

If you can put together a multimon system, I'd highly reccommend it. I run 2 monitors, and leave VC maximized on the 2nd monitor when debugging, that way if something happens I can see it / trace thru it.

I believe there's also a trick you can do with pumping text out through an MDA adapter, but I've never tried this.

Hope it helps...

Mason McCuskey
Spin Studios
www.spin-studios.com

You could use Lock() with DDLOCK_NOSYSLOCK flag to *prevent* a Win16Lock/Win16Mutex. So, your system wont hang. This doesn't work for Primary surface locks. Back buffer, and everything EXCEPT primary surface, the DDLOCK_NOSYSLOCK does what it says.

- prauppl

Im using Visual Studio 97 (C++) and currently learning to implement DirectDraw into my programs. Many times my program has spewed, leaving my PC parallized. Is there a way to catch DDraw bugs without the whole system dying on me?

i.e. lpDDS->GetDC(&hdc)
I once forgot to put ->ReleaseDC(hdc) in, surely there must be a way of catching this type of problem during compile??

I have also noticed that if the program is currently doing a DDraw procedure, and a "normal" error occurs i.e. array out of bounds, or divide overflow, the system will not catch it, and hang instead!!!

Ive tried using different debug settings, and even installed Norton CrashGuard, but still no luck.

Help ... anyone???

about the system hanging on bounds overflow and other stuff like that, sorry, C++ doesn't capture those.

about debugging fullscreen directx programs, you could try getting another computer and debugging over a network, that's what i do. the computer doesn't have to be good, my debug machine's a P166.