[VB6] Manifest Creator II

[LaVolpe]

Compilation Errors
Should you see an error like the following once your app is compiled...

... There are two possible reasons for it:
1. Your embedded manifest file size is not a multiple of 4 bytes. This is a bug with VB6 that SP6 fixed. If you don't have SP6 applied, do so. That fixes a lot more than the problem just mentioned. This tool now ensures it writes dword-aligned manifests to resource files anyway.
2. The manifest syntax/values may not be valid. You will need to view your Windows events log (from the control panel), look at the application log and find your application and the error shown above. In that error you'll see what line number and reason within the manifest (XML) that is causing the problem.

Here is an example of such a windows event error. The "version" value in that line of the manifest is a 4-part format, i.e., 1.0.0.0, not the 2-part format used: 1.0

Activation context generation failed for "C:\Program Files\...\CopyDatabaseWizard.exe". Error in manifest or policy file "C:\Program Files\...\CopyDatabaseWizard.exe" on line 8. The value "1.0" of attribute "version" in element "assemblyIdentity" is invalid.

Note: Adding a manifest with the Common Controls option allows your form's standard controls to be skinned using the current O/S theme. When adding this element, also start your project with the Sub Main located in a bas module, that routine is used to initialize the common controls. Do know that v5 of the common controls in your toolbox is skinnable, v6 in the toolbox is not. Tip: The Help menu can copy a typical Sub Main to the clipboard for pasting into that bas module. Tip: This option allows you to add alpha blended icons to buttons if desired. See post #10 below for an example.
Updated: On modern O/S, starting with Sub Main no longer seems to be required if using an embedded manifest. The manifest entry prompts the O/S to call the needed functions. However, on older O/S, there is a bug when using compiled OCXs created in VB that can cause a crash when the compiled application is closed. If that is happening, recommend using Sub Main. Even if not technically needed, does no harm. See this thread where that problem was discovered, jump to post #12 in that thread.

Tip: When exporting manifest to a RES file, the file does not need to exist. The tool will create the new RES file and then insert the manifest. However, don't export to a RES file belonging to a project that is currently open, write access will likely be denied. In this case, simply remove the res file from your open project, update it with this tool, then re-add the res file.

Note: Many options prevent modifying their values. This is simply because only one value is permitted and it is hard-coded. Tip: To show any attributes hidden in the tree view, edit values that are locked, or manually provide a value not in a displayed list of values, hold the shift key down while activating the context menu. Regardless, you cannot enter a blank value if the element/attribute has been flagged as its value cannot be blank.

Tip: Attributes cannot be selected/unselected. How to prevent optional ones from being exported? Set their value to empty/blank. In the "Output" window/form, choose option to not export empty attributes. Optional attributes have the context menu item "Erase". Several can have their values manually entered as a null string. Empty attributes that are exported will have a null value, i.e., <assemblyIdentity ... publicKeyToken=""/>. Optional is not always optional. For example, the publicKeyToken attribute is not optional if it applies. You, of course, are responsible for providing correct values for any item that can be manually entered.

Note: The Identity item cannot be unselected. It is the only required manifest XML element.

Tip: When displaying the Qualified Name context menu item, the base name and NameSpace submenus are FYI only. Since the treeview is designed to be human-friendly for the most part, the actual manifest element name and namespace are not necessarily displayed as they would be if reading the raw XML, if displayed at all. Those submenus give you that info.

Tip: VB is mostly DPI-aware. Adding the DPIAware option to your manifest will prevent your forms being stretched in higher DPI settings your users may be running your app in. However, VB6 is only mostly aware, and there are details that must be addressed. There is a tutorial of sorts on things to consider; here are a few:
- Use TrueType/OpenType fonts everywhere. First step: Assign the form a TrueType font as that is the font that is inherited by most controls added to the form afterwards, negating the need to individually set the font for most controls
- Image controls should have its Stretch property set to True else manually scale as needed
- PictureBox controls should NOT have its AutoSize property set to True else manually scale as needed
- Metafiles are DPI-aware. All other image types are not & may need to be scaled by you
- Controls without Top/Left, Width/Height properties (i.e., Line controls, etc) can fail to position/size correctly unless its form is saved in ScaleMode other than pixels. Always leave the form in twips ScaleMode and only change its ScaleMode at run-time if desired, i.e., in Form_Load
- Always test your app in highest DPI setting available when using the DPIAware option. Minimally, test at 175% DPI. If you are going to see issues, it will be there since internally, VB is not running at the same exact DPI.

Note: For those of you that are familiar with SetProcessDPIAware & SetProcessDPIAwareness APIs, Win10 can prevent their usage with the dpiAwareness and dpiAware elements. May only apply if your app, no embedded manifest, calls those APIs and an external manifest is applied to prevent the API usage. In other words, manifest trumps API calls.

Gotchas: When manifesting VB projects back in the day (XP), frames treated many child controls badly when rendering. That has been fixed for the most part... Except frames within frames. Try it and you should see the problem with the inner frame's caption. The workaround is similar to those old days: place the inner frame in a picturebox & that picturebox in the outer frame. Resize picturebox, change backcolor as needed, and make it borderless. See post #58 for an option to do this at runtime vs. fixing complex projects in the IDE.

IDE Gotchas: If you manifest your IDE for theming, you will likely lose the popup palette to select property colors during design-time. The palette is simply erased, but still there. To fix the problem, I have an add-in that can be used. See that thread