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

"David Kaye" <sfdavidkaye2@yahoo.com> wrote in message 
news:i5othp$b9e$2@news.eternal-september.org...
| 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?
| 

"David Kaye" <sfdavidkaye2@yahoo.com> wrote in message 
news:i5othp$b9e$2@news.eternal-september.org...
> 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?

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




 

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

"Abhishek" <user@server.com> wrote:
>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.

"Mike Williams" <Mike@WhiskyAndCoke.com> wrote:

>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) [....]

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

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


"David Kaye" <sfdavidkaye2@yahoo.com> wrote in message 
news:i5p202$3e4$1@news.eternal-september.org...
| "Abhishek" <user@server.com> wrote:
| >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.
| 

"David Kaye" <sfdavidkaye2@yahoo.com> wrote in message 
news:i5othp$b9e$2@news.eternal-september.org...
> 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?

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.

"Nobody" <nobody@nobody.com> wrote:

>If you put them there during install, then when another user 
>logs on, the files aren't there for him/her.

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.


"David Kaye" <sfdavidkaye2@yahoo.com> wrote in message 
news:i5p3at$3e4$5@news.eternal-september.org...
> "Nobody" <nobody@nobody.com> wrote:
>
>>If you put them there during install, then when another user
>>logs on, the files aren't there for him/her.
>
> That's the point.  The app I'm working on is user-specific.
>
>
>
>
> 

On 02/09/2010 21:53, Abhishek wrote:
> "David Kaye"<sfdavidkaye2@yahoo.com>  wrote in message
>> 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.
>
> here is my comparison of setup makers
> http://vb6zone.blogspot.com/2010/08/installers.html

Seconded.
This article gives a brief guide on doing it for a VB6 app.
http://hashvb.earlsoft.co.uk/Setups


-- 
Dee Earley (dee.earley@icode.co.uk)
i-Catcher Development Team

iCode Systems

(Replies direct to my email address will be ignored.
Please reply to the group.)

|
| 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?

  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.

"David Kaye" <sfdavidkaye2@yahoo.com> wrote in message 
news:i5p202$3e4$1@news.eternal-september.org...
> 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.

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. 

"Mayayana" <mayayana@invalid.nospam> wrote:

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

Thanks for some really really good pages!

"Bob Riemersma" <nospam@nil.net> wrote:

>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.

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.

VS Installer 1.1 is still available to download.

"Bob Riemersma" <nospam@nil.net> wrote in message 
news:OgR6IV8SLHA.2064@TK2MSFTNGP05.phx.gbl... 

|
| >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.
|
| 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:
  
>   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:

<snip>

>  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

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
-- 
Tony Toews, Microsoft Access MVP
Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
For a convenient utility to keep your users FEs and other files 
  updated see http://www.autofeupdater.com/