FiveTech Support Forums

I see some discussion here on using a .manifest file. In the past I always linked in one, but more recently it was easy to skip it. Instead of an external one in distribution, I simply included it in my .rc file. Reviewing discussions, that seems to be good.

Posts would suggest that current manifest files should include "a lot of things", but for what purpose is not explained. Apparently it is open ground for discussion by some groups relative to the use of them with Win 10 or 11.

So, I would like to know the current advice on including a .manifest file, should it be linked internally, and what should it consist of. A search of this forum seems to not provide a discussion of when, where, how to use them ... except some specific issues.

I'd love some input on this. Thanks.

TimStone wrote:I see some discussion here on using a .manifest file. In the past I always linked in one, but more recently it was easy to skip it. Instead of an external one in distribution, I simply included it in my .rc file. Reviewing discussions, that seems to be good.

Posts would suggest that current manifest files should include "a lot of things", but for what purpose is not explained. Apparently it is open ground for discussion by some groups relative to the use of them with Win 10 or 11.

So, I would like to know the current advice on including a .manifest file, should it be linked internally, and what should it consist of. A search of this forum seems to not provide a discussion of when, where, how to use them ... except some specific issues.

I'd love some input on this. Thanks.

I correctly use the one provided with the fwh package, in my case of the famous dialog http://forums.fivetechsupport.com/viewtopic.php?f=3&t=42287&start=0 where part of the say and tgroup controls was hidden it was because I used the TRANSPARENT clause to the DIALOG, removed this the dialog worked well it may be that there is a bug to the RADIO MENU class which hides part of the say controls

Silvio,

I asked the question because the only manifest files in the latest release of FWH seem to be outdated based on the few comments elsewhere in this forum.

They also have one for Windows 10, and 2 for Windows generic with 32 bit and 64 bit.

Perhaps we can have these reviewed and updated to use with Windows 10/11, both 32 bit and 64 bit. The second one is most important since my builds in the future, like Microsofts applications, will be 64 bit programs.

Tim

TimStone wrote:Silvio,

I asked the question because the only manifest files in the latest release of FWH seem to be outdated based on the few comments elsewhere in this forum.

They also have one for Windows 10, and 2 for Windows generic with 32 bit and 64 bit.

Perhaps we can have these reviewed and updated to use with Windows 10/11, both 32 bit and 64 bit. The second one is most important since my builds in the future, like Microsofts applications, will be 64 bit programs.

Tim

I tried to use the manifest for Windows 10 both the one provided by fwteam and others that I found on other industry forums.

In some procedures I found difficulties such as controls that did not work as they should.

then another quesion....since the first versions of fw I have always understood that fivewin creates windows or makes them create directly to the operating system, if it is really true excuse me for the round of words then because in win 10 or win 11 the style of the windows and Are the dialogs always in the style of win 7 or even win XP?

That is, I am afraid that fivewin does not exactly inherit the style of Windows otherwise what I wrote above is not explained. I am making a software and the main window has the style of Win 10, the dialogs and the child windows have the style of win 7 ....

how do you explain it?

I not believe the cause Is of manifest....

When attempting to generate a program with a .mak file, using the recommended library, I get errors if I include a Manifest ( using the samples in 22.06 ). If I do not include the manifest, I do not seem to have errors, but perhaps I'm missing something.

If I use Visual Studio 2022 Community, and it's IDE, to build the program, it has it's own internalized manifest embedded in the code. So not using an external manifest seems to work.

Of course I still have the issue with the checkbox builds in 64 bit, but since distributions are created with a .mak file, and that doesn't have the problem, I'll deal with that separately.

So perhaps we don't actually need a manifest file ? Sometimes I see that we need to reference it ( when advice is given ), but I'm not sure why. I was hoping someone could explain it's purpose here.

hi,

have a look "into" Manifest Files

c:\fwh64\samples\winxp\WindowsXP.Manifest c:\fwh64\samples\winxp\WindowsXP.Manifest64 c:\fwh64\samples\winxp\Windows10.Manifest the Windows10.Manifest begin with "other" than XP Version

so i "begin" with XP.Manifest64 and add "Rest"

---

this is my Manifest for 64 Bit

Dear Jimmy,

If we try to use your manifest file instead of the one provided with FWH, I get:

* Application successfully built *
No se pudo iniciar la aplicación; la configuración en paralelo no es correcta. Consulte el registro de eventos de la aplicación o use la herramienta sxstrace.exe de la línea de comandos para obtener más detalles.

Using FWH provided manifest for 64 bits then builds and works fine

hi Antonio,

when you look at Property "Details" of EXE can you see "FileDescription" :?:

i use different Settings in *.RC

Dear Jimmy,

> when you look at Property "Details" of EXE can you see "FileDescription" :?:

Only if you include a VERSIONINFO in your RC file

I use just these without any problems:

32bit
64 bit

hi Antonio,

Antonio Linares wrote:Only if you include a VERSIONINFO in your RC file

this is what i do

hi Enrico,

this is the "Standard" WindowsXP.Manifest for
32 Bit 64 Bit ---

i recommend to use "DPIAWARE" so it will NOT depend on Windows "Scale"

also "compatibility" (GUID for supportedOS) and "trustInfo" should be IHMO in Manifest

Enrico Maria Giordano wrote:I use just these without any problems:

32bit

Code (fw): Select all Collapse

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

64 bit

Code (fw): Select all Collapse

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

thanks...interesting the difference



could you tell me why in win 10 I have two types of windows?
the main is win 10 style and the child is win 7 style why?

hi Silvio,

Silvio.Falconi wrote:could you tell me why in win 10 I have two types of windows?
the main is win 10 style and the child is win 7 style why?

it is "by Design of xBase" ... :roll:

same is under Xbase++ and HMG that MDI Client have Windows 7 Style :(

---

as i remember i have use a "Trick" with Codejock Skinframework which also work on MDI Client

Jimmy wrote:hi Silvio,

could you tell me why in win 10 I have two types of windows?
the main is win 10 style and the child is win 7 style why?

it is "by Design of xBase" ... :roll:

same is under Xbase++ and HMG that MDI Client have Windows 7 Style :(

---

as i remember i have use a "Trick" with Codejock Skinframework which also work on MDI Client

why doesn't this happen in other programming languages? sample Delphi