Manifest files in resources

[Jonathan Payne]

Hi,

I am interested in adding a manifest file to the resources for a MFC
application.

When I create an AppWizard MFC app with a manifest file it adds the
following lines to the .rc file:

#ifdef _UNICODE
IDR_MANIFEST RT_MANIFEST "res\\TestManifest4.manifest"
#endif

As you can see, the manifest is only included in Unicode builds.

There are some reports that this conditional code is due to problems with
non-Unicode apps and manifest files. For example this thread here:

http://tinyurl.com/3haut

Does anyone know if these reports are correct and, if they are, what bugs
could be caused by using a manifest file with an ANSI app. Also, I would be
interested to know if the problems (if there are any) occur with file based
manifest files or just those included in resources.

There also appears to be a related problem where Visual Studio will strip
out any mention of manifest files from the .rc file if these lines are
changed. For example in this thread:

http://tinyurl.com/yv49c

I am hitting this bug quite frequently. I have tried hiding the RT_MANIFEST
resource in the ifndef APSTUDIO_INVOKED section but it is still removed.

I am considering moving the RT_MANIFEST resource to a .rc2 file to
completely hide it from the IDE to stop this happening.

Before doing that, I would like to know if this behaviour is deliberate and
if any of it is, what bugs are Microsoft trying to hide / protect us from?
I don't want to put lots of work into this, just to hit some new bugs down
the line.

In case this post was too dull, here is the quick summary question: Is it
safe to put an RT_MANIFEST file into a .rc2 file to enable themes on Windows
XP for both Unicode and ANSI builds and are there any bugs in the
compiler/ide/operating system that may be caused by doing this (and are
their any bugs that would occur because the manifest file is in the
resources rather than in a file).

Thank you for taking the time to read this rather dull post,

Jonathan
Senior Software Engineer
Serif (Europe) Ltd

[David Lowndes]

>There are some reports that this conditional code is due to problems with

non-Unicode apps and manifest files. For example this thread here:

http://tinyurl.com/3haut

Does anyone know if these reports are correct and, if they are, what bugs
could be caused by using a manifest file with an ANSI app.
Jonathan,

They're correct as far as I'm aware. The problem is plainly visible in
an MFC application that uses a CEditView. The root problem is that
EM_GETHANDLE message returns a buffer of WCHAR (rather than char), but
other than that, I'm not aware of other ANSI only issues.
Also, I would be
interested to know if the problems (if there are any) occur with file based
manifest files or just those included in resources.
The problem is the use of the newer (V6) common controls, so it's
irrelevant of how you use the manifest.
I am considering moving the RT_MANIFEST resource to a .rc2 file to
completely hide it from the IDE to stop this happening.

Before doing that, I would like to know if this behaviour is deliberate and
if any of it is, what bugs are Microsoft trying to hide / protect us from?
Dunno.
I don't want to put lots of work into this, just to hit some new bugs down
the line.

I think a lot of people will have used manifests in ANSI builds and
not experienced any problems - but all you can do is try it with your
application and test it thoroughly. The issue in question didn't
become publicly visible for quite some time after XP's release.

Dave

[Jonathan Payne]

Thank you for your reply and the info about EM_GETHANDLE.

I don't think this bug will affect us. The only thing I am still confuesd
about is why Microsoft felt it was necessary to disable themes on
non-Unicode builds just for this bug (it doesn't seem that bad as I would
imagine that CEditView windows arn't that widly used).

I think I will just try and hide the RT_MANIFEST resource so the resource
edit can't delete it and see how things go.

Jonathan

"David Lowndes" <da****@example.invalid> wrote in message
news:ml********************************@4ax.com...

There are some reports that this conditional code is due to problems with
non-Unicode apps and manifest files. For example this thread here:

http://tinyurl.com/3haut

Does anyone know if these reports are correct and, if they are, what bugs
could be caused by using a manifest file with an ANSI app.
Jonathan,

They're correct as far as I'm aware. The problem is plainly visible in
an MFC application that uses a CEditView. The root problem is that
EM_GETHANDLE message returns a buffer of WCHAR (rather than char), but
other than that, I'm not aware of other ANSI only issues.

Also, I would be
interested to know if the problems (if there are any) occur with file basedmanifest files or just those included in resources.

The problem is the use of the newer (V6) common controls, so it's
irrelevant of how you use the manifest.

I am considering moving the RT_MANIFEST resource to a .rc2 file to
completely hide it from the IDE to stop this happening.

Before doing that, I would like to know if this behaviour is deliberate andif any of it is, what bugs are Microsoft trying to hide / protect us from?
Dunno.

I don't want to put lots of work into this, just to hit some new bugs

downthe line.

I think a lot of people will have used manifests in ANSI builds and
not experienced any problems - but all you can do is try it with your
application and test it thoroughly. The issue in question didn't
become publicly visible for quite some time after XP's release.

Dave

[Jeff Partch [MVP]]

"Jonathan Payne" <jp****@NOSPAM.serif.com> wrote in message
news:%2****************@TK2MSFTNGP09.phx.gbl...

Thank you for your reply and the info about EM_GETHANDLE.

I don't think this bug will affect us. The only thing I am still confuesd
about is why Microsoft felt it was necessary to disable themes on
non-Unicode builds just for this bug (it doesn't seem that bad as I would
imagine that CEditView windows arn't that widly used).

I think MS position is/was that the V6 common controls are internally
UNICODE and should therefore only be used in UNICODE apps. Period.
--
Jeff Partch [VC++ MVP]