User Tools

Site Tools


tplxpvistamanifestglobal.htm
Navigation:  Application Generator >====== Manifest Support ====== Previous pageReturn to chapter overviewNext page

Include Default XP Manifest

Check this box to include a default Manifest file in your application. When your program runs in the XP environment, this instructs the XP theme manager to render your controls with the new look and feel of the Windows XP environment. The manifest file is ignored on other Windows platforms (95/98, 2000, NT, and Vista). This option adds the necessary MANIFEST logic to the application's export file.

C6H0012.jpg

The above setting should be used for XP Manifest only (e.g., applications running on a Windows XP O/S). If you plan to use a Vista Manifest, use the following options instead:

Generate Manifest

Check this box if you need to export an external XP manifest file that is associated with this application. This external manifest file is required when migrating your application to Clarion Win32, to support the latest XP visual styles and the extended UI support.

Link Generated Manifest in Project

Check this box to automatically include the external Manifest generated above into your distributed applications. This option eliminates the need for you to include the .manifest file with your application.

Configure Manifest for Vista

Check this box to enable additional options to be used with the Vista manifest. These options are explained in detail below:

C6H0012.jpg

If you attempt to run an application on UAC-enabled Vista without an embedded manifest file, any code or user action event attempting to display a simple file dialog can throw unhandled security exceptions. There are many scenarios where you might need to elevate the UAC access level for standard users, especially when porting a legacy application to Vista, and a complete UAC-refactor is not possible. There are three levels available in an application manifest for invoking requested execution privileges.

Vista Execution Level

Choose from one of three execution privilege levels:

asInvoker

The standard user token is used to start the process.

If your application doesn't require any special privileges, use the asInvoker execution level. Your users will run the program transparently without encountering a Vista popup each time they invoke it. Attempted writes to forbidden areas will fail rather than being virtualized.

highestAvailable

The application runs with the highest privileges the current user can obtain.

If your application doesn't require a full Administrator account but does require certain privileges, such as those accorded to accounts that are members of the Backup Operators group, use the highestAvailable execution level. An ordinary user will not encounter the elevation prompt and your app will not succeed in exercising the elevated privileges. A user who has one or more of the privileges that trigger Vista elevation will encounter the Vista elevation popup when he runs your application. If his account has sufficient privileges, your application will function as intended; otherwise not.

requireAdministrator

Prompt standard users for administrative credentials.

If your application requires an account that is a member of the Administrators group, use the requireAdministrator execution level. This is necessary if your application writes to certain areas of the Windows Registry such as HKEY_LOCAL_MACHINE, needs to write within C:\Program Files or C:\Windows, needs to install drivers, or needs to perform other tasks that ordinary users are restricted from doing. Each time your application is run, the user will encounter the Vista elevation popup and will need to authorize your app to run.

In summary, the execution level you choose for your manifest will depend on the requirements of your application.

C6H0012.jpg

Applications ported from early versions of Windows that could (if built for Vista) work as standard-user applications may require administrative token access via the credentials prompt or administrative approval mode until they can successfully incorporate the best UAC practices.

Application requires UIAccess

Check this box to set the UIAccess to “True”. In this state, the application is allowed to bypass UI protection levels to drive input to higher privilege windows on the desktop. This setting should only be used for UI Accessibility applications.

With this option unchecked, the target application does not need to drive input to the UI of another window on the desktop. Applications that are not providing accessibility should set this flag to false. Applications that are required to drive input to other windows on the desktop (on-screen keyboard, for example) should set this value to true.

Do you really need UIAccess?

This capability is generally intended only for accessibility utilities. If you do need UIAccess enabled, then the executable needs to be digitally signed, and must be installed under %windir% or %ProgramFiles%.

If Application requires UIAccess is set to FALSE (unchecked):

The application does not need to drive input to the UI of another window on the desktop. Applications that are not providing accessibility should set this flag to false. Applications that are required to drive input to other windows on the desktop (on-screen keyboard, for example) should set this value to TRUE.

If Application requires UIAccess is set to TRUE (checked):

The application is allowed to bypass the UI protection levels to drive the input to higher privilege windows on the desktop. This setting should only be used for UI Accessibility applications.

UIAccess is only enabled if the Vista execution level is set to requireAdministrator.

Set Windows7 compatibility to Vista

Adds the VISTA parameter to the MANIFEST directive. This add to the Windows7 compatibility section information that this application supports Windows Vista.

Set Windows7 compatibility to Windows7

Adds the WINDOWS7 parameter to the MANIFEST directive. This add to the Windows7 compatibility section information that this application supports Windows7.

Make controls inside the TAB transparent

Sets the transparent (TRN) attribute to every OPTION, GROUP, RADIO, STRING, CHECK, and PROMPT controls that are placed inside a TAB control. This gives these controls a more pleasing appearance when displayed inside a TAB control that uses the new Visual Styles.

tplxpvistamanifestglobal.htm.txt · Last modified: 2021/04/15 15:57 by 127.0.0.1