Using the Debug mode ((F10) V.S 2005

Hello...

Been using debug a lot in the past with VS 6.0 C++ (Console Applications)... In VS 2005 (with Windows Apps) i noticed the window doesn't activate while you step into your program... I use watch window so would like to enter input data while debugging... I also tried adding a break point, which i notice doesn't work if i run the program (cntrl+F5), not unless i debug (F5) but then again can't maximize/restore the window in this mode...

Any ideas on how to debug whilst interacting with the user interface/window?

Since Window applications rely on the WM_PAINT message to redraw, you can not redraw the application when it is also stopped in the debugger [at least unless it's multithreaded - and I'm not suggesting you should multithread your application - it will just make things even harder on you].

That's just the way debugging in windows [and other windowed environments that draw from within the app] works.

Console apps are different because the actual console window is owned by a different process than the one running in the console, so the drawing is done by the console management process, not the application itself [the application just updates WHAT should be drawn on the console].

I don't know if Vista changes this - it has changes in the way that windows are drawn to the display, but I suspect it doesn't change how the debugging works.

--
Mats

The window needs to respond to several messages sent by windows, or it will be marked as unresponsive, frozen and become white eventually.
The ONLY way to solve it is have a message loop running.
What I typically do is spawn a thread for each event handler (such if you click a button) and thus have the message loop constantly in the thread that created the window.
You can then add, for example, message boxes randomly in your code if you need to see the window. Remember that VS will break ALL threads, so it will break the message loop thread too.

Quote:

---

Originally Posted by Elysia

The window needs to respond to several messages sent by windows, or it will be marked as unresponsive, frozen and become white eventually.
The ONLY way to solve it is have a message loop running.
What I typically do is spawn a thread for each event handler (such if you click a button) and thus have the message loop constantly in the thread that created the window.
You can then add, for example, message boxes randomly in your code if you need to see the window. Remember that VS will break ALL threads, so it will break the message loop thread too.

---

Shoo! sounds like Chinese to me but will get there one day ... "THREADS"!!!!

Quote:

---

Originally Posted by Elysia

The window needs to respond to several messages sent by windows, or it will be marked as unresponsive, frozen and become white eventually.
The ONLY way to solve it is have a message loop running.
What I typically do is spawn a thread for each event handler (such if you click a button) and thus have the message loop constantly in the thread that created the window.
You can then add, for example, message boxes randomly in your code if you need to see the window. Remember that VS will break ALL threads, so it will break the message loop thread too.

---

I need to do this but not sure how, could you perhaps give a simple code example?

Hmmm. I don't use Win32 api, but...
Firstly, do you know how to use threads?

The solution is to use a multiple monitor system or use remote debugging. However another simpler solution is to run your program non-maximized. You should still be able to switch to each task via the task bar.

I'm able to debug programs on my dev box as well as my client box (remote) at work with no problems. I'm not sure exactly what your troubles are. Please explain and I may be able to help more.

The big problems I have at home are I don't have a multi-monitor system and I don't have a client box that is the equiv of my dev box so most of my Direct3D code won't run on the client. However I can run windowed which, while annoying at times, still does the trick.

Quote:

---

Originally Posted by Elysia

Hmmm. I don't use Win32 api, but...
Firstly, do you know how to use threads?

---

Up to a degree but yes i do...

Code:

---

WM_CREATE:
    _beginthread(MyThreadFunc,0,NULL);

..................   

VOID MyThreadFunc(PVOID pvoid)
{

    while(TRUE)
      {
      // thread code
      }
 
}

---

what should go in thread code?

Quote:

---

Originally Posted by Bubba

The solution is to use a multiple monitor system or use remote debugging. However another simpler solution is to run your program non-maximized. You should still be able to switch to each task via the task bar.

I'm able to debug programs on my dev box as well as my client box (remote) at work with no problems. I'm not sure exactly what your troubles are. Please explain and I may be able to help more.

The big problems I have at home are I don't have a multi-monitor system and I don't have a client box that is the equiv of my dev box so most of my Direct3D code won't run on the client. However I can run windowed which, while annoying at times, still does the trick.

---

Are you using Visual Studio 2003/2005/2008? cause apparently non of those allow to debug in this manner!

Quote:

---

Originally Posted by csonx_p

Are you using Visual Studio 2003/2005/2008? cause apparently non of those allow to debug in this manner!

---

That's not true.
Whatever problem you're having it's not to do with the IDE or compiler, because the only bit of debugging functionality that was removed in the later compilers, that I can see, is the ability to detach from a single process rather than all (moan moan). I have used all those versions - a lot.

Quote:

---

Originally Posted by iMalc

That's not true.
Whatever problem you're having it's not to do with the IDE or compiler, because the only bit of debugging functionality that was removed in the later compilers, that I can see, is the ability to detach from a single process rather than all (moan moan). I have used all those versions - a lot.

---

if you read what matsp is saying here, then you guys are confusing me... Oh! sorry, he's not referring to VS, but to windows programming... Perhaps my question to bubba is if he/she was programming windows API or not!

But unfortunately, VS breaks all threads and thus also breaks the message loop, so your window appears frozen. This is the source of the problems.
I don't know if anyone else know/has a workaround for that.

Strange, any new function i add won't be executed (gets skipped) in a debug mode... I pressed F10 continuously to step over and two of my functions are skipped :confused: Well, this could be happening even when i run the program...

Quote:

---

Originally Posted by csonx_p

Strange, any new function i add won't be executed (gets skipped) in a debug mode... I pressed F10 continuously to step over and two of my functions are skipped :confused: Well, this could be happening even when i run the program...

---

Are you sure you don't get a compiler error or some other inconsistency in your building of the application? Try doing a complete rebuild (clean build) of all your code. The usual cause for these things is that the code the compiler generated, and the source code that the debugger is showing, are out of sync.

--
Mats

You do realize that F10 steps over, right? It will execute the entire function and break afterwards.
Just making sure that I'm understanding you right.