Okay, you can have files installed into directories such as $(AppPath),
$(WinSysPath), and so forth, but what is the magic word to deploy files into
the User's path, that is C:/Documents and Settings/username/Application Data
and its equivalent in Vista/Windows 7? 

I need to put user-specific files in place but can't figure out the magic
name.  Anyone?

start > run > %appdata% > ok

Show quoteHide quote

You can do it using the SHGetSpecialFolderLocation function. This has
actually been superseded by the GetFolderLocation function (and by the
SHGetKnownFolderIDList function in Vista onwards) but it still works fine on
all current systems. Others here will probably come up with code for the
other two functions I have mentioned, but in the meantime try the following
(on a Form with a Command Button):

Mike

Option Explicit
Private Declare Function SHGetSpecialFolderLocation _
  Lib "Shell32.dll" (ByVal hwndOwner As Long, _
  ByVal nFolder As Long, pidl As ITEMIDLIST) As Long
Private Declare Function SHGetPathFromIDList _
  Lib "Shell32.dll" Alias "SHGetPathFromIDListA" _
  (ByVal pidl As Long, ByVal pszPath As String) As Long
Private Type SH_ITEMID
    cb As Long
    abID As Byte
End Type
Private Type ITEMIDLIST
    mkid As SH_ITEMID
End Type
Private Const CSIDL_APPDATA = &H1A
Private Const CSIDL_LOCAL_APPDATA = &H1C
Private Const MAX_PATH As Integer = 260

Private Function fGetSpecialFolder(csidl As Long) As String
Dim sPath As String
Dim IDL As ITEMIDLIST
fGetSpecialFolder = ""
If SHGetSpecialFolderLocation(Me.hWnd, csidl, IDL) = 0 Then
  sPath = Space$(MAX_PATH)
  If SHGetPathFromIDList _
          (ByVal IDL.mkid.cb, ByVal sPath) Then
    fGetSpecialFolder = Left$ _
            (sPath, InStr(sPath, vbNullChar) - 1) & "\"
  End If
End If
End Function

Private Sub Command1_Click()
Print "App Data (roaming) = " _
    & fGetSpecialFolder(CSIDL_APPDATA)
Print "App Data (non roaming) = " _
     & fGetSpecialFolder(CSIDL_LOCAL_APPDATA)
End Sub

Thanks.  I wish I didn't have to launch a separate EXE just to copy a few
files into the user directory tree....bummer.

CSIDL
http://msdn.microsoft.com/en-us/library/bb762494(v=VS.85).aspx

From your answers I infer that there is no way to rewrite the deployment
wizard with a magic name such as $(AppData) or something similar and have it
work?  Remember that the deployment wizard allows only the previously coded
magic names to be used.  It does not allow new ones, so I'd have to find the
source code and rewrite it, assuming it would even work.

Kind of a bummer that the people who designed VB 6.0 didn't think to easily
allow the inclusion of files in the user's directory area.

Use setup program like InnoSetup, at first they may seems to be difficult to
use but once you know it will be easy.
and if you still want to use it then you can customize the P&D wizard. these
constant values are in the P&D source code in basCommon.bas file.

here is my comparison of setup makers
http://vb6zone.blogspot.com/2010/08/installers.html


Show quoteHide quote

On 02/09/2010 21:53, Abhishek wrote:
Seconded.
This article gives a brief guide on doing it for a VB6 app.
http://hashvb.earlsoft.co.uk/Setups

  That's true, but it's not a big deal to rewrite the
PDW setup1.exe itself. And you can use the SH*
APIs to get the path. Microsoft has messed up the
folder path system unnecessarily (they have such
a talent for that :) but you can still use the older
SH* APIs on all systems. Ignore the newer ones
unless you're *only* dealing with Vista/7.

   While things have to be done just right in a setup
program, there's no special magic. Mostly it's just
copying files and Registry values. The PDW is just
a VB6 program for doing that. You can add to it,
change it, whatever... Just remember to log
any actions that you want reversed on uninstall. The
PDW uninstaller uses the log in the program folder
as a guide. If you look at that log and at the setup1
code you'll see the logging functions are obvious
and simple.

   See here for rebuilt PDW samples that allow for
custom GUI, add Desktop icon, QuickLaunch icon, App
Data folder, program size listing in Add/Remove...
while also cutting down the size of setup1.exe and
eliminating setup.exe:

http://www.jsware.net/jsware/vbcode.php5


(I haven't got around to updating the QuickLaunch
icon option to work on Vista/7. We had a discussion
about it here at one point, and it's apparently doable,
but so far I just haven't got around to it.)

A lot of people like Inno. I don't think I've ever
heard any real criticism of it. But you *can* update
the PDW, and that provides a lot more options than
things like Inno or MSIs -- especially in terms of
appearance. The installer is what you want it to be,
and using a custom GUI is very simple. By contrast,
Inno seems to be stuck with a boring, generic window,
and using custom graphics in MSIs....or doing *anything*
with MSIs, for that matter, is a tedious, complex task.

Thanks for some really really good pages!

Show quote Hide quote You have two issues here.

One is that installations normally don't put per-user files in place.  If
installing per-machine (for all users) the installer can put a Start Menu
shortcut into the "All Users" profile, but if users require individualized
application data the application should copy from a master set of initial
values on first run.  Those might be things like per-user settings files.

However it is possible to run installs per-user to install for a single
user.

Your second issue is that you're using the obsolete PDW, which was replaced
by Visual Studio 6.0 Installer twice shortly after VB6 came out.  The first
was a 1.0 release, and then came an improved 1.1 release.

Using VSI 1.1 and Windows Installer technology will let you create setups
that can run per-user or per-machine.  A per-user .MSI package is perfectly
capable of creating application data folders under LocalAppDataFolder and/or
AppDataFolder and installing designated files there.  A per-machine package
can create application folders under CommonAppDataFolder, set any necessary
security (even Full Control for Everyone) on these folders, and install
designated files in them.

So everything you need has been available since sometime in 2000.  The trick
is getting VSI 1.1 now.  In the past year Microsoft pulled it from their
download site.

Hard to blame Microsoft though.  They gave you nearly a decade to get up to
speed.

I had it, but when I moved to a new machine I guess I didn't install all the
service packs.  I'll go look and see what I have.

   Be sure to look into it before going too far. The PDW
was not "replaced by Windows Installer". Microsoft came
out with Windows Installer and they've pushed it as the
standard install system. It's popular in corporate
environments for several reasons:

* It provides methods to do software rollbacks and patches.

* The installed software enumeration functions of WMI are
just a wrapper around Windows Installer, so they only work
for software installed via MSI file.

....Etc. Those kinds of functions are important to
a lot of network admins who have to manage multiple
installs across a network.

  The downside is that Windows Installer is extremely,
unnecessarily, complex. And none of the tools to work
with it are very good. If you look at popular software to
see what others have done you'll find that very few people
are using MSIs....with good reason.  People writing smaller
software programs are typically using Inno or Nullsoft:
http://en.wikipedia.org/wiki/Nullsoft_Scriptable_Install_System

   Larger companies that serve corporate clients are more
apt to use Windows Installer. But even then, they're not
usually using W.I. directly. They're typically using InstallShield,
which is a wildly overpriced wrapper around W.I. that makes
W.I. more usable and adds extra functionality via I.S. DLLs.
It's still a big mess and the latest version of I.S. is about
$2,000! ...Not the sort of investment that makes sense for
most people.

On Sat, 4 Sep 2010 16:56:02 -0400, "Mayayana"
<mayayana@invalid.nospam> wrote:

<snip>

As I want to distribute MSIs so the IT department is more comfortable
with my utility I've found that the open source "Windows Installer XML
(WiX) toolset" is quite decent.

Create MSI file
http://wix.sourceforge.net/manual-wix3/overview.htm
Intro
http://wix.sourceforge.net/manual-wix3/main.htm
Tutorial
http://www.tramontana.co.hu/wix/

The tutorial alone solved all my basic requirements so I was able to
get my DLL installing in a few hours.  (Well, once I solved a very
stupid mistake in the command line compiler that was entirely my own
fault.  <smile>  I forgot the ""s around a file path that had spaces.)

Tony

VS Installer 1.1 is still available to download.

Show quoteHide quote

It's not a good idea to install to a user specific folder. Instead, install
the files to $(AppPath), or CSIDL_COMMON_APPDATA, and then when your
application runs, it checks if the files are in %AppData%, and if not, copy
them there. If you put them there during install, then when another user
logs on, the files aren't there for him/her.

To get the folder from your app, follow Mike's suggestion. Use
CSIDL_APPDATA. CSIDL_LOCAL_APPDATA is for large files only. See the recent
thread with subject "file and folder permissions" for details.

That's the point.  The app I'm working on is user-specific.

The DB installer does install a shortcut only to the user, so it must know
where the user folder is. However I just don't know how to code it, maybe
you can look around the installer file.


Show quoteHide quote

Looking for VC6 newsgroup
Error 481 Invalid picture
Global class and WithEvents
Distibution of VB6 program
Lockup Continues
Why doesn't this work (sendmessage)
Showing/Using Sort arrows on vb6 listviews?
Closing Grouped instances in the taskbar
Componenet not installed correctly by PDW
Error 5: ERROR_ACCESS_DENIED when accessing registry in Windows 7