Results 1 to 9 of 9

Thread: [VB6] Class: PathLinks - Tame App.Path Under Vista+

Threaded View

  1. #1

    Thread Starter
    Join Date
    Feb 2006

    [VB6] Class: PathLinks - Tame App.Path Under Vista+




    A VB6 self-instantiating Class to be used once (elevated) after application installation to:
    • Pre-Vista: Create any necessary empty data subfolders under App.Path.
    • Vista+: Relocate your App.Path data subfolders to the user R/W "Public" folder.

    The purpose is to let your setup install your application into Program Files, yet let all users run your application and let it read and write files in the data subfolders without changing your application program logic!

    This is one way to solve the "App.Path problem" for installed VB6 applications.

    • Under Windows XP or earlier, nothing new is done except to create empty data subfolders under App.Path on the first run.
    • Under Windows Vista or later, if the first run is done elevated your data subfolders under App.Path are relocated to "Public" and symlinks are dropped into App.Path so your program can automagically find them!
    • Source form in-Project Class, no DLL need be created. The compiler instantiates a global instance of the Class so you don't have to.

    Author Name

    Bob Riemersma

    System Requirements

    Windows 95 with Desktop Update or later.

    Under Windows Vista or later the "Public" special folder must not have been relocated off the "Program Files" drive!

    License Info

    Public domain.

    Use at your own risk for any purpose: private, commercial, governmental, educational, or institutional. Absolutely no warranty or offer of support!

    Misc. Notes
    • Don't try to create an instance of PathLinks. A global instance named PathLinks is automatically created by the compiler.
    • If your "Public" folder has been relocated to a different drive from where your App.Path is then any pre-existing data subfolders in the list passed to PathLinks.Publish() will fail on the move attempt!
    • Do not "publish" subfolders under App.Path that contain DLLs, OCXs, etc. This is just for data and data folders you need read/write access to for any user running your program.
    • Data files placed "naked" right under App.Path without a subfolder can not be helped by PathLinks. If necessary rewrite your program to use these from inside a subfolder.
    • Create your setup package as you would on Windows 2000 or XP. Include any data files in the package, to be deployed to a subfolder under App.Path as always.
    • The only extra step after installing is a user must run your program elevated one time before anyone uses it normally.
    • Once again, pre-Vista PathLinks does nothing except create empty data subfolders for you as required. From there your program runs as always.
    • Exception: If your program tries to MakeDir an empty work folder under App.Path it may fail under this scheme. Let PathLinks create your empty folder under App.Path or else add error checking around your MakeDir statements.
    • You could also write a separate small program that just calls PathLinks.Publish() to be run elevated right after installing. Then your actual application program or programs will not need PathLinks in them at all!

    Tested On

    Windows XP SP3, Windows Vista SP2, Windows 7 RC.

    The Demo

    PathLinks is included here as a demonstration project. Note that there is a demojunk subfolder with one text file in it. This is used to demonstrate that data put into an App.Path data subfolder by your setup does indeed get moved to the "Public" folder when run elevated under Vista+ the first run.

    To run the demo:
    • Open the Project and compile it.
    • Run the program under Vista or later, note that it prompts the user to run it as administrator for this first run.
    • Run the program elevated. Close it.
    • Run the program unelevated. Click the buttons to test its ability to write and read data in the defined data subfolders. Close it.
    • Note that the data subfolders are no longer in the App.Path folder. Use Windows Explorer to look inside the "Public" special folder (try C:\Users\Public for most systems) to see where the app data folders have been moved to. Also note the symlinks pointing to these new folders that were created in the App.Path folder.

    Also consider packaging the compiled program and installing it and running it on XP and Windows 7 test systems.

    General usage

    Add PathLinks.cls to your program's Project. Add initialization code similar to that you can see in the demo's Module1.bas module. Compile, test, create a setup package. Add instructions telling the user to run the program once elevated under Vista or later.

    Closing Comments

    This is not the "right way" to handle this issue. However a lot of programmers may find it an elegant alternative to "the right way." It only requires minimal changes to an existing program, which will seem to "see" App.Path as working as always.

    The source code in PathLinks.cls contains a block of comments documenting its usage in more detail.
    Last edited by dilettante; Sep 6th, 2010 at 10:28 AM. Reason: Serious bug. Removed attachment, but will repost soon!

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts


Click Here to Expand Forum to Full Width