C / C++ / MFC

Re: VC6 to VC2008 migration

19-Jul-11 22:04

I got similar errors when moving from 2003 to 2010 recently. The cause was a static library that was part of my project that bound the runtime library statically rather than dynamically. For some reason this was never a problem before, but VS 2010 didn't like it.

My advice is check the libs that are part of your solution and make sure they all use the same settings regarding the runtime library being used. note that it doesn't matter whether the lib is bound statically or dynamically to your executable - the main point is that all libs must use the same version of the runtime library. (and I believe the same is true for the choice of MFC library)

_Flaviu20-Jul-11 4:05

_Flaviu

20-Jul-11 4:05

Thank you, I will try.

Re: VC6 to VC2008 migration

_Flaviu20-Jul-11 19:51

_Flaviu

20-Jul-11 19:51

Was the libcmt.lib problem : in project settings, link, input, I ignore libcmt library and goes almoust fine ... I set manually manifest.xml, and didn't like it to VS2008.

Why debugging doesn't work properly when I choose "USE PRECOMPILED HEADER"?

Cold_Fearing_Bird19-Jul-11 19:01

Re: Why debugging doesn't work properly when I choose "USE PRECOMPILED HEADER"?

19-Jul-11 19:01

<< VS2008 professional edition >>
If I use precompiled header "stdafx.h", sometimes debugging just doesn't work well, some of the variable value don't show up. Then I turned off using precompiled file, everything gets back to normal.It's only my prolbem? or does it ever happen to you, could there be a solution ?

Richard MacCutchan19-Jul-11 21:44

Richard MacCutchan

19-Jul-11 21:44

This is most unlikely; what is more likely is that you have some old information in your .PCH file (or in stdafx.h) that is causing the problem. Try doing a CLEAN and rebuild and check again what is happening. It would be useful to look closely at exactly what just doesn't work well and give specific details if it happens again.

The best things in life are not things.

Re: Why debugging doesn't work properly when I choose "USE PRECOMPILED HEADER"?

Cold_Fearing_Bird19-Jul-11 22:17

Re: Why debugging doesn't work properly when I choose "USE PRECOMPILED HEADER"?

19-Jul-11 22:17

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.

here's my stdafx.h

#include <windows.h>
#include <windowsx.h>
#include <iostream>
#include <iomanip>
#include <string>
#include <vector>
#include <map>
#include <complex>
#include <fstream>
#include <sstream>
using namespace std ;
#include <strsafe.h>
#include <GdiPlus.h>
using namespace Gdiplus ;
#include <CommCtrl.h>
#include <cassert>



class __Init_win32_app
{
private:
	ULONG_PTR m_gdiToken ;
public:
	__Init_win32_app() ;
	~__Init_win32_app() ;
private:
	BOOL InitCommonControls() ;
} ;

//stdafx.cpp

#include "stdafx.h"

#pragma comment( lib, "gdiplus.lib" )
#pragma comment( lib, "comctl32.lib" )
#pragma comment(linker,"\"/manifestdependency:type='win32' name='Microsoft.Windows.Common-Controls' version='6.0.0.0' processorArchitecture='*' publicKeyToken='6595b64144ccf1df' language='*'\"")

__Init_win32_app::__Init_win32_app()
{
	GdiplusStartupInput gdiplusStartupInput;
	GdiplusStartup(&m_gdiToken, &gdiplusStartupInput, NULL);
	InitCommonControls() ;
}
__Init_win32_app::~__Init_win32_app()
{
	GdiplusShutdown(m_gdiToken);
}

BOOL __Init_win32_app::InitCommonControls()
{
	INITCOMMONCONTROLSEX iccex ;
	iccex.dwSize = sizeof( iccex ) ;
	iccex.dwICC = 0													
//		|	ICC_ANIMATE_CLASS								// animate
//		|	ICC_BAR_CLASSES									//tool bar, status bar, track bar, tooltip
//		|	ICC_COOL_CLASSES									//re bar
//		|	ICC_DATE_CLASSES									// data and time picker
//		|	ICC_HOTKEY_CLASS								//hot key
//		|	ICC_INTERNET_CLASSES						// IP
//		|	ICC_LINK_CLASS										// hyper link
		|	ICC_LISTVIEW_CLASSES						// list view, header
//		|	ICC_NATIVEFNTCTL_CLASS					// navtive font
//		|	ICC_PAGESCROLLER_CLASS				// pager
//		|	ICC_PROGRESS_CLASS							// progress
		|	ICC_STANDARD_CLASSES						// button ,edit, static, listbox, combobox, scrollbar
//		|	ICC_TAB_CLASSES									// tab, tooltip
//		|	ICC_TREEVIEW_CLASSES						// tree view, tooltip
//		|	ICC_UPDOWN_CLASS								// up down
//		|	ICC_USEREX_CLASSES							// ComboBoxEx
//		|	ICC_WIN95_CLASSES								// animate, header, hotkey, list_view, progress bar, status bar, 
		;																			//tab, tooltip, toolbar, trackbar, tree_view, up down
	return ::InitCommonControlsEx( &iccex ) ;
}

__Init_win32_app win32_app ;

Could you help me with it?

Stefan_Lang19-Jul-11 22:48

Re: Why debugging doesn't work properly when I choose "USE PRECOMPILED HEADER"?

19-Jul-11 22:48

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.

Cold_Fearing_Bird19-Jul-11 23:14

Re: Why debugging doesn't work properly when I choose "USE PRECOMPILED HEADER"?

19-Jul-11 23:14

Thanks for improving my codes. Laugh | :laugh:

It can be compiled, but I would love to keep the code anomaly to minimum, in case something undefined jumps out of nowhere, and we both know it's a time eater,HOHO.

Richard MacCutchan19-Jul-11 23:52

Richard MacCutchan

19-Jul-11 23:52

Cold_Fearing_Bird wrote:
Could you help me with it?

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.

The best things in life are not things.

Re: Why debugging doesn't work properly when I choose "USE PRECOMPILED HEADER"?

Stefan_Lang19-Jul-11 22:11

Re: Why debugging doesn't work properly when I choose "USE PRECOMPILED HEADER"?

19-Jul-11 22:11

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

Cold_Fearing_Bird19-Jul-11 22:22

Re: Why debugging doesn't work properly when I choose "USE PRECOMPILED HEADER"?

19-Jul-11 22:22

My header files( stdafx.h, stdafx.cpp, some routine files) are in a different folder than the project folders I usually work on. Does that tend to cause problem?

Stefan_Lang19-Jul-11 22:26

How to turn off the disassemble functionality

19-Jul-11 22:26

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

Cold_Fearing_Bird19-Jul-11 5:48

19-Jul-11 5:48

When debugging my App, my VC always steps into disassemble file list and never gets back to my cpp file.It's very annoying How to turn off it?

Richard MacCutchan19-Jul-11 6:15

Richard MacCutchan

19-Jul-11 6:15

If you close the disassembly window it should return to the .cpp file. This usually happens when you press F11 or click on Step Into during the debugging session.

The best things in life are not things.

Rajesh R Subramanian19-Jul-11 7:04

Rajesh R Subramanian

19-Jul-11 7:04

The disassembly window will be hidden by default. I think you must have enabled the "Show disassembly if source code is not available" option. Turn it off, and the disassembly won't show up.

"Real men drive manual transmission" - Rajesh.

«_Superman_»19-Jul-11 8:40

«_Superman_»

19-Jul-11 8:40

You can find the option at Tools -> Option -> Debugging -> General -> Enable Address-level debugging -> Show disassembly if source is not available.

«_Superman_»
I love work. It gives me something to do between weekends.

Microsoft MVP (Visual C++)

Polymorphism in C