Distribute new font with PDW

[dcronje]

Is it possible that I can include a new font in the PDW so that it automatically installs when the user installs the program?

[isnoend07]

Pdw is hard to modify. You can probably put it in a resource file and install it from Sub Main if it doesn't exist

[dilettante]

Add the font to the package using the Included Files panel of the PDW. In the Install Locations panel set this file's Install Location to $(Font) using the dropdown.

That's about it.


It's all in the PDW documentation in your VB6 manuals (or the MSDN CDs that came with VB/VS 6.0).

[dcronje]

Thanks a lot.

In the meantime I developed the following problem:My setup file does not install my program on other users' machines because of the old dreadful "Setup cannot continue becasue some system files are out of date...". I found that the culprits are the following lines in the Setup1.lst file:

File9=@RICHED32.DLL,$(WinSysPathSysFile),,,5/7/98 12:00:00 AM,174352,4.0.993.4
AM,152848,6.1.97.82
File12=@MSWORD.OLB,$(WinSysPath),,$(Shared),2/19/01 9:12:38 PM,626688,10.0.2619.0
File13=@comctl32.dll,$(WinSysPath),,$(Shared),1/18/08 11:26:34 PM,531968,5.82.6001.18000

When I remove them from the Setup1.lst file, the program installs perfectly, but when the user tries to run it, the .exe file is missing in the App folder. Any hints?

[dilettante]

This and other errors can be produced when you erroneously try to distribute files that cannot be redistributed. Some of them are OS dependent, and you can't move one from XP to Win98 and expect them to work, etc. Some can't even be moved from XP SP2 to XP SP1 without wreaking havoc.

PRB: Access Violation During Application Setup When File in Use (http://support.microsoft.com/kb/216368)

In this case you're trying to distribute one that is part of Word, a license infraction that will not succeed anyway. Users have to install Word to get it. The other two are system components, but riched32.dll is a special case that the VB6 PDW should already know how to handle.

INFO: Distribution Issues with Riched32.dll (http://support.microsoft.com/kb/197580)


One thing you ought to be doing is keeping the PDW's VBDEP.INI file up to date. This is in Program Files under the PDWizard folder beneath the VB98 folder. There is a section name [Do Not Redistribute] that lists items the PDW should not try to package and install with applications.

This list is not updated by VB6 Service Packs. You need to stay on top of changes over time and manually update it, and much has changed since that list was put together in 1998.

Most of us just stumble onto these as we have problems and update as we need to. Short term you could just "uncheck" comctl32.dll from the files to be packaged (within a run of the Wizard).


Your Word problem is bigger, and you want might to see some of the FAQs and other threads here about the hazards of early binding Office objects and what to do instead. Also consider looking through:

Using early binding and late binding in Automation (http://support.microsoft.com/kb/245115)

INFO: Use DISPID Binding to Automate Office Applications Whenever Possible (http://support.microsoft.com/kb/247579/)


I never recommend editing Setup.lst by hand. Problems there are often just a symptom of another bigger issue or just easier to correct with better accuracy (and permanance) by other means.

[dcronje]

Thanks for the answer.
In the meantime I used the PDW on a machine running XP (mine running Vista) for the same program and now no errors are reported.

[dilettante]

Most likely Vista just looked askance at your setup when it tried to install comctl32.dll and ignored it if that's where you're installing TO. Vista has more safeguards against rogue installers trashing things than previous OSs, though XP will attempt to head them off as well.

Don't try to deploy to downlevel systems with such a setup though.

You are really supposed to set up the Redist folder under the PDW with DLLs and OCXs to be deployed rather than ever letting it package from System32. This lets you positively choose what versions get deployed.

Almost nobody outside of a corporate setting seems to follow this discipline though and often it doesn't hurt anything... until you get bitten. Most commercial developers create MSI packages instead and draw from Installer merge modules instead of System32.

Remember: the PDW was really a stopgap included in VB6 to support VB5 users upgrading and until Visual Studio Installer was ready. Even the VB6 CDs contain a TXT file recommending you download and use VSI instead. The PDW works though, it was just never updated except for glaring bugs.