Re: PDW Fun
- From: "MikeD" <nobody@xxxxxxxxxxx>
- Date: Mon, 13 Jul 2009 01:26:48 -0400
I'll tackle these inline.
"Bee" <Bee@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message news:2AB8717A-FF4E-48B3-84DB-D98FFB8675E3@xxxxxxxxxxxxxxxx
This is my third attempt to post.
The previous two time nothing got through.
So now I am trying to package my app.
I'll bet there are similar questions for Inno or MS (msi) installer etc.
Using Package and Deployment Wizard.
Too many questions without any help making decisions.
1) Missing Dependency Information - do I check the box or not?
What is the criteria to check one or more of the itmes listed?
e.g. GdiPlus.dll
msimg32.dll
psapi.dll
quartz.dll
sapi.dll
wiaaut.dll
wmp.dll
Why would I check or not check any of these?
I left them as defaulted since I did not know what to do.
I'm not familiar with msimg32.dll and wiaaut.dll. The rest you probably shouldn't (and possibly legally can't) redistribute with the exception of psapi.dll. It is redistributable and has no dependencies.
2) Out-of-date dependency information
mscomctl.ocx
so what?
How do I fix or not bother?
It just means the version of this OCX you're using is not sync'ed to its ..dep file. Not uncommon. 99.9% of the time it's safe to ignore for this particular OCX. You probably want to check the box to not get warned about it again. Alternatively, update its .dep file so that the version information in it matches the actual version information of the OCX file.
Stupid PDW considered this even though it was not used on any form.
It seems that if it is on the components bar even without actually being
used the
PDW wants to include it. (see below)
In Project Properties, go to the Make tab and make sure "Remove Information about unused ActiveX Controls" is checked. Even better, if you're not using a control, remove it from the Toolbox (I assume that's what you mean by "components bar"). The same goes for the References dialog box. Remove any reference you're not actually using. PDW includes in the package it makes any file in the Toolbox or References dialog, even if you don't actually use it in your program. This is because PDW reads the .VBP file for referenced ActiveX files.
3) Single Cab vs multiple cab, why a choice? what advantage? Floppies?
Primarily, yep. Gotta remember, back in 1998 when VB6 came out, floppies were still used. But there is still an advantage to using multiple cabs regardless of distribution media. If your package is relatively large, 10 MB or greater (sorry, forget exact threshold value), you should create multiple cabs. The reason is that a PDW Setup installs VERY slowly if all files are in a single .cab file and that .cab file is fairly large. It's always been that way and it's something that MS just never fixed (at least to my knowledge). It has to do with how Setup1.exe extracts files from the ..cab file(s). It actually performs better when there are several .cab files.
4) Start Menu Items.
What do I do here?
This is one app so why would I add a group or new item? confused.
You should create a new group and create the shortcut to your app in that. You might also want to create shortcuts in this group for a readme file, the help file, etc. If you don't create a group (IOW, do nothing), a shortcut to your program will be created in the Start Menu's Programs (or All Programs, depending on Windows version). Your Start Menu shortcuts, even if there's only one, should be in their own group.
5) Install locations
Why not just use the defaults?
What advantages are there to use other options?
Usually, the defaults are fine. But as with everything, there are always exceptions. For example, you might have written your own DLL or OCX that is used ONLY by your own programs (note plural). In that case, you MIGHT want to install those files into a subdirectory of the system's Common Files folder. PDW's default is most likely to install them in either the application folder (not a good choice for a file used by more than 1 app) or in the System32 folder (again, not always the best choice since this folder is already cluttered with tons of files). You should NOT change the default install location for files included with VB which you can legally redistribute. This would include almost all OCX and DLL files included with VB. You would normally only change the default install location for files of your own authoring.
6) Shared Files
why would I want to share files? Or not?
I left them unchecked since I did not know what to do.
This could be somewhat important (probably not as much now as it was 10 years ago, but still can be important). In order for PDW's uninstaller to properly uninstall a file and work well with other installers and uninstallers that "follow the rules", you need to check this IF the file is used by more than 1 app, be it your own app or an "unknown" app. This option doesn't mean you're sharing the file in the sense of making it available to other persons. It means the file is used by more than 1 program. Again, remember that VB6 and PDW are more than 10 years old. Back in 1998, when a shared file (shared by programs, not shared among persons) was installed, a reference count was supposed to be kept in the Registry which indicated the number of applications which installed the file (or more appropriately, the number of times the file was "installed"). When an app was installed, it was supposed to increment this value by 1 (or create the Registry value for the file and set it to 1 if the file was being installed for the first time). During uninstallation, this reference count was to be decremented by a value of 1 and if it reached 0 after being decremented, the file was to be deleted. Problem was many installers and uninstallers didn't do any of this right, so that reference count was seldom accurate. Bottom line....if the file is not used ONLY by this one app, IMO you should check the shared file box. In today's reality however, it probably doesn't make much difference. But I still say check this box if the file could be shared among apps.
On my second attempt after taking the CommonDialog off the components bar
yielded this.
---------------------------
Package and Deployment Wizard
---------------------------
Unexpected error number 80004005 has occurred: Automation error
Unspecified error
---------------------------
OK
---------------------------
Hmmm...
Closed the IDE and reloaded the app and still have the same error.
Hmmm...
Cleared the temp files and still have the same error.
Hmmm...
Constant cdlCancel was used even though CommonDialog was not used.
I could remove the CommonDialog from components bar with no problem.
It did not complain that it was still using cdlCanel.
Anyway, sorted that out and now packaging again without CommonDialog.
But still all of the above questions.
Not sure what to make of this. If you used the cdlCancel constant, I don't think VB would complain about removing the control. VB only warns about that if the control is sited (placed on a form or other container). However, you would get a compile-time error about the constant not being defined (assuming Option Explicit is being used and you didn't write your own declaration for the constant). But I don't know why that would cause an error in PDW unless you were compiling within PDW and it just didn't know how to better report the problem of the undefined constant.
--
Mike
.
- Follow-Ups:
- Re: PDW Fun
- From: mayayana
- Re: PDW Fun
- References:
- PDW Fun
- From: Bee
- PDW Fun
- Prev by Date: Re: PDW Fun
- Next by Date: Re: Unicode Support in VB6
- Previous by thread: Re: PDW Fun
- Next by thread: Re: PDW Fun
- Index(es):
Relevant Pages
|
Loading
