469,642 Members | 1,271 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,642 developers. It's quick & easy.

Preprocessor definition not "inherited" when converting from VC++6

I imported a VC++6.0 project into VC++7.1. The conversion operation makes a mess with Preprocessor Definitions, adding a "$(NoInherit)" for each file.

For example: I had a DLL project in VC++6.0 where the definitions were:

_UNICODE,_DEBUG,_WIN32_DCOM,WIN32,_WINDOWS,_WINDLL ,_AFXDLL,_USRDLL

In VC++7.1, these are the preprocessor definitions of the project (right-click the project in Solution Explorer and choose Properties -> C++ -> Preprocessor):
_DEBUG;_WIN32_DCOM;WIN32;_WINDOWS;_USRDLL
And the following are the preprocessor definitions of the .cpp files:
_UNICODE;_DEBUG;_WIN32_DCOM;WIN32;_WINDOWS;_WINDLL ;_AFXDLL;_USRDLL;$(NoInherit)

Note that _UNICODE, _WINDLL and _AFXDLL have disappeared from the main project settings... I wonder why.

Is there a way to change this irritating behaviour? I'd like the source file to share settings as in VC++6.0.
If the only way is to fix it manually, shall I simply remove $(NoInherit) from each .cpp file, or add $(Inherit) ?

Furthermore, when I add a new source file to the project, its "preprocessor definition" text box is empty, and clicking on the "(...)" button I see (in the "preprocessor definition" dialog) that the checkbox "Inherit from project" is checked by default, and that the "inherited" preprocessor definitions are:

_DEBUG
_WIN32_DCOM
WIN32
_WINDOWS
_USRDLL
_WINDLL
_AFXDLL
_UNICODE
UNICODE

Note that this time we have _UNICODE, _WINDLL and _AFXDLL again, but we have also UNICODE without underscore (I read on a newsgroup that "The _UNICODE macro is used for the C run-time header files, and the UNICODE macro is used for the Win32 header files"). But where do these four phantom preprocessor definition come from?

If I compile the new .cpp file, I get a compiler warning (placed at the line where I include "StdAfx.h"):
warning C4005: 'UNICODE' : macro redefinition
d:\Programs\VisualStudio2003\Vc7\atlmfc\include\af xv_w32.h(123) : see previous definition of 'UNICODE'

The "previous definition" refers to the following lines of "afxv_w32.h"
#ifdef _UNICODE
#ifndef UNICODE
#define UNICODE // UNICODE is used by Windows headers
#endif
#endif

Another post on a newsgroup says, "All you need to do is define _UNICODE. The Microsoft headers automatically define UNICODE for you if _UNICODE has been defined."

But I didn't define UNICODE, it seems to appear from thin air... Can this "double definition" be a problem? How can avoid the warning?
Note that the "General -> Character Set" option has been set automatically to "Use Unicode Character Set".

Thank you very much
Paolo
Nov 17 '05 #1
2 6240
"=?Utf-8?B?UGFvbG8=?="
<to***************************@web.tiscali.it/fanelia/noi.html>
wrote in news:71**********************************@microsof t.com:
For example: I had a DLL project in VC++6.0 where the
definitions were:

_UNICODE,_DEBUG,_WIN32_DCOM,WIN32,_WINDOWS,_WINDLL ,_AFXDLL,
_USRDLL

In VC++7.1, these are the preprocessor definitions of the
project (right-click the project in Solution Explorer and choose
Properties -> C++ -> Preprocessor):
_DEBUG;_WIN32_DCOM;WIN32;_WINDOWS;_USRDLL And the following are
the preprocessor definitions of the .cpp files:
_UNICODE;_DEBUG;_WIN32_DCOM;WIN32;_WINDOWS;_WINDLL ;_AFXDLL;
_USRDLL;$(NoInherit)

Note that _UNICODE, _WINDLL and _AFXDLL have disappeared from
the main project settings... I wonder why.

_UNICODE, _WINDLL, and _AFXDLL are still defined in the main
project settings. Check the C/C++|Commandline node in the project
properties and you'll find them listed for the project.

In VS2002 (and up) these settings are imported using "property
sheets" (which is a level of property inheritance that we opened
up to users in VS2005) that specify these values as base values
for the project to inherit from. You control whether or not these
values are defined by changing the properties on the
"Configuration Properties | General" node. For example, setting
the configuration type to be a DLL will include the property sheet
that will define _WINDLL, etc.

Thanks,
--
Tarek Madkour, Visual C++ Team
This posting is provided "AS IS" with no warranties, and confers
no rights.
Nov 17 '05 #2
"Tarek Madkour [MSFT]" <ta****@online.microsoft.com> wrote in
news:Xn*****************************@207.46.248.16 :
_UNICODE, _WINDLL, and _AFXDLL are still defined in the main
project settings. Check the C/C++|Commandline node in the
project properties and you'll find them listed for the project.

In VS2002 (and up) these settings are imported using "property
sheets" (which is a level of property inheritance that we opened
up to users in VS2005) that specify these values as base values
for the project to inherit from. You control whether or not
these values are defined by changing the properties on the
"Configuration Properties | General" node. For example, setting
the configuration type to be a DLL will include the property
sheet that will define _WINDLL, etc.


More importantly... sticking all the preprocessor definitions on
the files with a $(NoInherit) is a bug in VS2003.

The right fix is to just remove all the per-file preprocessor
definitions (make it inherit from the project).

You can do this manually or you can write a macro and use the
object model. Alternativly, if you have access to VS2002 you could
upgrade the project using VS2002 and then upgrade it again from
VS2002 to VS2003. VS2002 did not have this bug and will
consequently do the correct upgrade.
Thanks,
--
Tarek Madkour, Visual C++ Team
This posting is provided "AS IS" with no warranties, and confers
no rights.
Nov 17 '05 #3

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

6 posts views Thread by Christian Brechbühler | last post: by
235 posts views Thread by napi | last post: by
7 posts views Thread by Bennett Haselton | last post: by
3 posts views Thread by Paul Michaud | last post: by
24 posts views Thread by Nak | last post: by
5 posts views Thread by Rob | last post: by
12 posts views Thread by Steve Pope | last post: by
2 posts views Thread by Emmanuel Deloget | last post: by
8 posts views Thread by Rasmus Kromann-Larsen | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.