Thanks for reply, I thihnk you're right.
Although it was the variables that from my cpp file didn't show up and leave the poor blue-cube(stands for variable)lonely there, I still believe it's my stdafx.h going awry.
Umm, does this even link? AFAIK the PCH file is simply the object file created from stdafx.cpp, and if that were true you would be binding the implementation of your class __Init_win32_app to every object file in your project, thus causing error 2005 (' ... already defined in ...'). But I may be wrong.
In any case, I see no reason at all to put your class definition in there. Try moving your class declaration to a separate header and the implementation to a separate source file. The rest of your stdafx.h looks ok to me. stdafx.cpp should only contain the include statement.
For a start take all that extraneous code out of stdafx.cpp; that file should only contain the very first statement (#include "stdafx.h"). Also remove all the '__Init_win32_app' class definitions from stdafx.h and place them in a local project include file.
I doubt this is related to using PCH. More likely, the debugging information simply wasn't up to date. Changing the setting to use or not use a PCH will force a complete rebuild that of course created the neccessary information and that is why your problem was solved after changing that.
Unfortunately VS was never really good at keeping the debug information accurate. You sometmes do have to force a complete rebuild, either by doing a Clean first, or just by choosing Rebuild All.
P.S.: one of the possible reasons for your debug information to mess up is when files change that are not actually part of your solution, e. g. header files from third party libraries. VS obviously does not check these files, and I never managed to find a setting to fix that. Back in the time when we were still using makefiles I'd simply add a dependency, but I have no idea what to do nowadays...
No, as long as you don't get a 'file not found' error you're good. You could put any file anywhere as long as you provide the neccessary paths where to look for them. And you'll notice if something is missing as soon as you try to compile (or link).
I am writing a program using VC++ with MFC,
I added some dialog boxes and I want that once one of the dialog is opened by DoModal()
all the buttons on the parent dialog will be disabled,
How can I do it?
Just a query: Why do you want to disable the controls on the parent dialog i.e. only for the look and feel?. Since the dialog being popped up is a result of the DoModal thing, the hit on the parent dialog will not work unless you dismiss the popped dialog.
On the other hand as suggested with the parent dialog pointer you can disable the control on it in the InitDialog of the dialog being popped up.
You talk about Being HUMAN. I have it in my name
I have a dialog that has a menu and clicking on the menu items causes to open other dialogs
The problem is that, while one dialog is opened the user can click other menu items and open more dialogs and its causes me a mess.
How can I declare that the main dialog will be a parents of the other dialogs?