[RESOLVED] Question about P&D wizard

[batman321]

Hi,

The P&D wizard works great but there's one area for concern. I am selling my VB6 program online and one of my users had Windows 7 Ultimate. Anyway, by default, the P&D wizard uses "program files\your directory" for VB6 application installs. My program works with Microsoft Word 2007 using the mail merge feature. Anyway, when my user tried to use the letter wizard (send database.mdb data to mail merge tool in MS word), MS word, couldn't recognise the database (it appeared blank) and received many error messages. When my user saved (this option exists in my program) the database file location to another directory (no longer the program files directory), he could use the mail merge in Word (i.e. all the data loaded from the database). I wonder if its the file permissions from his "program files" directory was to blame for this? Should I change the "program files" default install folder in the P&D wizard installation? I think it was his machine.

Thanks

[dilettante]

It is hard to tell quite what is going on here.

My guess is your program writes to App.Path files, which isn't proper. Instead of changing where your program installs, you should change where it writes things.

Anything that a user is going to "play with" via Windows Explorer, Word, etc. is really supposed to go into the Documents (formerly "My Documents") folder. Even then your program should let the user tell it where they want the file to be via something like the CommonDialog control's ShowSave method.

Anything internal to the program like settings files and other R/W resources should go into either the user's LocalAppdata folder or the CommonAppdata folder depending on whether it is per-user or per-machine data. Even then your setup package should create subfolders under those folders, generally following the Company\App format. if you are using a simple setup like those made by the PDW, it might be easier to have your program create these folders at first run (check, if not there create them).


Even if your program "works on XP" it probably does so by breaking the rules. App.Path (which often is under Program Files for installed programs) hasn't been a proper place for writeable data since the Windows 95 Desktop Update. Windows in the post-XP modern era enforces that rule now.

By rights, Windows should be terminating such a program with a file access or security violation error. But I'm guessing Windows sees your program as "legacy code" and is applying the file virtualization appcompat shim to it. Unless your program has a manifest marking it "Vista aware" Windows will sort of chuckle and jolly you along.


So I'm guess that your program tries to write or update a file (Jet MDB?) located under Program Files. Windows looks at your program, tries not to laugh, and redirects your program's file access to the VirtualStore under LocalAppdata. When the user tries to use this file later via some non-legacy code (such as Word 2007) it only sees the original copy of the data under Progam Files.


There is a presentation on this at:

http://www.youtube.com/watch?v=Mbv7PcPxDb8

Sadly the guy has a moderately thick south Asian accent and he apparently recorded his narration while sitting in a bath tub, but with careful listening you may make it out.

Most of the many, many official Microsoft presentations on this are long gone. They were published back in 2006 and programmers are expected to already know this stuff now.

[batman321]

Also, I play lots of PC games, and the default directory the game tries to install to is "Program Files". This directory on my computer contains most folders on my PC. These games are new as well 2000-2012, and probably before.

[si_the_geek]

They should be installing to "Program Files", because that is where executable files etc belong - but not everything associated with a program does, because these are not the old DOS days any more.

Data files belong in appropriate folders, as explained above. The exception to this is files that will never be written to (eg: video files for cut-scenes in a game). If you check properly, you should find that most of the games you've got store lots of things under "Program files", but also store various data files in the proper places.


There is another explanation (and a link to a 1998 article, which came in paper form with some copies of VB6) in the article Where should I store the files that my program uses/creates? from our Classic VB FAQs (in the FAQ forum)

[batman321]

I have read everything you guys are saying, but its only 1 file that is causing the problem. My database.mdb. Once that file was saved to another directory, my program has no more problems.

[si_the_geek]

Indeed... and all we are saying is that one file should be installed to an appropriate location.

If you want your program to work properly, follow the rules of the operating systems you are working with. In this case, the rule you are violating has been in place for well over 10 years, across many versions of Windows - you've just been lucky until now (it would have failed for many users before).

[batman321]

Hi team,

Just some questions:

If I copy my database.mdb file to user's "Documents" folder:

1. Does the "Documents" folder exist on Windows XP/Vista/Windows 7? What if the "Documents" folder name changes in future OS? My software is for XP/Vista/7 at the mo.

XP has a "My Documents" folder
Vista has a "Documents" folder
Win7 has a "My Documents" folder. In my program, the file save options shows this folder as "Documents" only.

2. What if the "Documents" folder read/write properties change. For example, if a user changes the "Documents" folder to "read only"?

3. Could users alter the name of "Documents" folder in any way? This will make the path file invalid and my database will not be found.

4. What if the "Documents" folder is deleted? The OS will automatically recreate this folder because its part of the OS?

I'm basically saying "is the Documents folder on users machines the best folder to save my database to, despite all the user changes, barriers, restrictions it could encounter?!

Thanks guys.

[Nightwalker83]

The "Documents" folder is available on all the operating system you listed but not always in the same location for each operating system. Since you are using VB6 you might want to look into the "Special Folders" api which, retrieves the path, etc of special folders for the installed operating system. You might even want code to check the current operating system.

[batman321]

I just found out the "Documents" folder in Win7 was hidden. I had to change the folder options to "show hidden files and folders". Will this be a problem if this folder is hidden on Win7 user's PCs?

[dilettante]

I just checked two Win7 systems and the Personal (i.e. "Documents" or back to "My Documents" again in Win7, go figure) folder is not hidden. Perhaps the one you looked at had been infected at some point? That's a common reason for this issue.

The real question is why you'd put .MDB files in there at all???

That location is for the user's working documents, i.e. things they need to mess around with directly. Normally a program's database would go under either LocalAppdata or CommonAppdata, which are meant as program workspaces.


Your program should never try to find any of these locations by name. That's why Shell32.dll supports two APIs for looking up this info. One easy way to get this info is via the COM API:

• Set a reference to Microsoft Shell Controls And Automation
• Look up the paths by Special Folder value, using late binding to avoid a binary compatibility glitch in some versins of Windows

    Dim strPath As String
    
    With CreateObject("Shell.Application").NameSpace(ssfPERSONAL).Self
        strPath = .Path
    End With

or:

    Dim strDocs As String
    Dim strLocalAD As String
    
    With CreateObject("Shell.Application")
        strDocs = .NameSpace(ssfPERSONAL).Self.Path
        strLocalAD = .NameSpace(ssfLOCALAPPDATA).Self.Path
    End With

etc.

The Shell Special Folder constants are documented in your VB6 copy of the MSDN Library (i.e. the online help). You could also go the bulkier route and use Shell32.dll's non-COM API (i.e. a few bulky Declares and wrapper code).

But you never want to dump files under LocalAppdata, ComonAppdata, etc. Instead you should be putting them into a unique subfolder, usually based on items such as App.CompanyName and App.Title.

If using CommonAppdata you also need to set security on your subfolder to permit your users to write there. This is why such a folder should be created during program installation, since the installer should already be running elevated anyway.

But I think I'm repeating myself.

[batman321]

I can retrieve the path name from the LocalAppdata folder (Appdata\Program Name) for all my target OS and store my database there. I'm using the code:

    Dim strDocs As String
    Dim strLocalAD As String
    
    With CreateObject("Shell.Application")
        strDocs = .NameSpace(ssfPERSONAL).Self.Path
        strLocalAD = .NameSpace(ssfLOCALAPPDATA).Self.Path
    End With

Is the code above using late binding? That means I don't have to reference *shell32.dll" under project/references because this code creates it during runtime (i.e. createobject). Is this correct?

The problem I'm experiencing now could be a "binary compatibility glitch". Two of my .txt files are having data written to them immediately after the P&D wizard has run/after it finishes installing program (both .txt files have correct values in the <support> folder).

How do I stop this?

[Nightwalker83]

No, you still need to reference "shell32.dll" in your project! I have used the some code in a number of my own projects.

[batman321]

I included the "shell32.dll" file with my project but I can't find it listed in the "support" folder or in the "SETUP.LST" file.

In the P&D wizard, under "included files", shell32.dll is not listed with included files. Isn't it suppose to look at all the references and say lets add "shell32.dll" because the user ticked the box.

**Update...

I registered the shell32.dll file using regsvr32 and now the P&D wizard recognises this file.

**UPdate...

Ok..I nearly nailed it. My program does what its suppose to but during setup it says it can't register shell32.dll . That's my only problem.

"an error occurred while registering c:\program files\<program name\shell32.dll"

It's the ONLY error message I get now...I have fixed everything else!!!

[si_the_geek]

Is the code above using late binding? That means I don't have to reference *shell32.dll" under project/references because this code creates it during runtime (i.e. createobject). Is this correct?

Assuming you have defined the constants (ssfPERSONAL and ssfLOCALAPPDATA) somewhere in your code, it is Late Binding, and therefore a reference should not be needed.

I included the "shell32.dll" file with my project but I can't find it listed in the "support" folder or in the "SETUP.LST" file.

That is because it is trying to stop you doing something really bad - you should not be distributing that file.

Ok..I nearly nailed it. My program does what its suppose to but during setup it says it can't register shell32.dll . That's my only problem.

"an error occurred while registering c:\program files\<program name\shell32.dll"

That is because Windows is protecting itself... if you succeeded, there is a very high chance that Windows would be unusable.

[batman321]

Thanks for your help! I fixed this by defining the constant ssfLOCALAPPDATA

  Private Const ssfLOCALAPPDATA = &H1C