manifest files

[jasperblij]

Hi all,

I'm having some trouble with manifest files.
On Vista everything works fine if I add the well know initialization function to the VB app en then place <exename>.exe.manifest file with this content in the same dir as the exe file itself:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0"> 
<assemblyIdentity 
    version="1.0.0.0" 
    processorArchitecture="X86" 
    name="transavia.com.dispatcher.dispatcher"
    type="win32" 
/> 
<description>transavia.com dispatch manager</description> 
<dependency> 
    <dependentAssembly> 
        <assemblyIdentity 
            type="win32" 
            name="Microsoft.Windows.Common-Controls" 
            version="6.0.0.0" 
            processorArchitecture="X86" 
            publicKeyToken="6595b64144ccf1df" 
            language="*" 
        /> 
    </dependentAssembly> 
</dependency> 
</assembly>

There are two problems:
1. On Windows XP computers all background values of all objects seem to get black, resulting in unreadable radio buttons.
2. On some computers the exe won't even startup, users only head a sound heard when something fails, removing the manifest file helps to solve it.

Does anyone know solutions to one of these (or both ) problems?

Greetings,
Jasper

[some1uk03]

This has been discussed hundreds of times... you might wanna give the forum a lil search on manifest files.. I'm sure you'll find a solution.

[isnoend07]

i had some problems with a manifest and the fix was to do this:
remove the standalone="yes"?>
Only other difference i see is <description>Executable</description>

<?xml version="1.0" encoding="UTF-8" ?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
    <assemblyIdentity 
        version="1.0.0.0" 
        processorArchitecture="X86" 
        name="MyCompany.My AppTitle"
        type="win32" />
    <description>Executable</description>
    <dependency>
        <dependentAssembly>
            <assemblyIdentity 
                type="win32" 
                name="Microsoft.Windows.Common-Controls" 
                version="6.0.0.0" 
                processorArchitecture="X86" 
                publicKeyToken="6595b64144ccf1df" 
                language="*" />
        </dependentAssembly>
    </dependency>   
</assembly>

Have had no problem on xp,vista and win 7

[jasperblij]

Thanks mate, I'll give it a try

[reacen]

Did you try to initialize it on a Sub Main() ? With "on error resume next" ? Im not sure if its gonna help, just a thought.

[westconn1]

put radio buttons in pcturebox as container instead of frame

[isnoend07]

Thanks mate, I'll give it a try

As westconn1 stated put radio buttons in pcturebox is a must. If you wanted to keep the frame then put a borderless picturebox inside the frame containing the radio buttons. I have this method throughout my app.

[jasperblij]

As westconn1 stated put radio buttons in pcturebox is a must. If you wanted to keep the frame then put a borderless picturebox inside the frame containing the radio buttons. I have this method throughout my app.

Why is that?

[isnoend07]

Why is that?

Don't know why, maybe just a bug with xp. When i was using win2k it did not have the problem of course didn't need a manifest, but i switched my app to xp
and provided a manifest everyone of my Radio buttons were black and had to be put in a picturebox

[dilettante]

It is more of an issue with the way some VB6 controls are constructed. They can't pick up the theming alone or something, yet by putting them into some types of containers the problem goes away.

I can't recall any alternative work-around.

[7edm]

This is all explained in this threed which show that instead of using a picturebox you can subclass the frame. Now why on earth would I like to do that? Because frames are "windowless" while pictureboxes are heavier and add much more overhead to your app.

All credit goes to LaVolpe, I just pasting the url ;-)

[dilettante]

I agree, windowless containers are the problem.

However subclassing is generally more work and just produces more risks such as potential IDE crashes. There are "safe" subclassing methods but they are even more work.