Switched from VC6 to VC .NET 2002, new problems

Started by
13 comments, last by Archi 19 years, 6 months ago
The code ran fine for me on 2003, save for a few unused parameters warnings.

and unrelated..

I would suggest modifying your winmain while loop so that you do peekmessage first, before testing if msg.message == wm_quit.

Advertisement
Quote:Original post by WanMaster
??
ow would a window be able to process messages, if your stuck in a while loop in the MsgProc?


Sorry for that one, it's 2 a.m. in Belarus so I'm almost sleeping ;)
Quote:Original post by Hylo
The code ran fine for me on 2003, save for a few unused parameters warnings.

and unrelated..

I would suggest modifying your winmain while loop so that you do peekmessage first, before testing if msg.message == wm_quit.


Yep. Like that:
    while( true )    {        if( PeekMessage( &msg, NULL, 0, 0, PM_NOREMOVE ) )        {            if( !GetMessage( &msg, NULL, 0, 0 ) )                return msg.wParam;            TranslateMessage(&msg);            DispatchMessage(&msg);        }        else        {		UpdateFrame();        }    }


EDIT: tagged source
Quote:Original post by ktuluorion
I actually think now that it is crashing somewhere else along the line. I can't really see the debugger because I am using DirectX Graphics, and I don't have window switching in yet so I can't flip back and forth.


When developing D3D based applications, for exactly this reason, I'd recommend always working in windowed mode until you absolutely need to run fullscreen.

When you absolutely do need to do stuff in fullscreen, if at all possible multiple monitors or remote debugging tend to make life much easier.

For the sake of debugging this current problem, I'd just change the D3DPRESENT_PARAMETERS you're passing to CreateDevice() to use Windowed mode instead - a simple 2 second change to 3 lines of a structure will be much easier and quicker than a few hours of guess based debugging.


The fact that your code worked under MSVC 6 may simply indicate that it's unwittingly doing something "risky" that's dependent on the way the MSVC 6 compiler is generating code.

Just because a program appears to run fine, it doesn't mean it's totally bug free! [smile]

Simon O'Connor | Technical Director (Newcastle) Lockwood Publishing | LinkedIn | Personal site

Quote:Original post by S1CA
Just because a program appears to run fine, it doesn't mean it's totally bug free! [smile]


"If program is bug free, then the bug is in the compiler" (c) unknown coder.

This topic is closed to new replies.

Advertisement