Printable View
Quote:
Originally Posted by dilettante
What ive done is create 2 install packages.. One for XP and one for Vista. The XP installer defaults the installation to Program Files, the Vista defaults the installation to the Users folder.
The program currently uses the Shell command to run the patcher (i shoulda called this updater, nothing is actually "patched"), should i modify the code to include this "runas" thing your talking about?
Using the runas verb with ShellExecute is just an alternative (for Vista) to using an elevation manifest.
If Users is fully read-write you don't even need the manifest, but I doubt that. Actually if users will be installing elevated you can just use Programs/Program Files for both XP and Vista as long as you move any writeable data files to a folder under CSIDL_COMMON_APPDATA:
Method 4: Install to a common per machine location
Quote:
Another method is to install just the non-executable game data to a subdirectory of SHGetFolderPath CSIDL_COMMON_APPDATA. This is a shared location for all users and can be modified by Standard User applications.
Ok this is getting my attention...
I went to your link and read the whole page, the SHGetFolderPath and CSIDL_COMMON_APPDATA things are interesting...
But a few issues, first.. I dont understand either of them... the SHGetFolderPath looks like some kinda API command in VB, and the CSIDL_COMMON_APPDATA looks like a path in the registry... but i dunno!!!
Also the SHGetFolderPath on that link doesnt work. Can you briefly explain how to use these? That link says by doing this, you can install the app to Program Files, and without even needing administrator privelages, you can update all the files necessary... Which is a big thing to me because before, when installing the program to Program Files under vista, i had to change the security settings for each user on the apps folder so that it could update the files, if i didnt do that... The program couldnt even modify the contents of its own files, or create anything... it was annoying!
SHGetFolderPath() and friends are for getting the paths to special folders (duh) and working with them. CSIDLs are how you describe which folder you're interested in.
You still need to install elevated into Programs, but the data can be elsewhere.
Have you looked at AppEx Class, Assists Vista Programming?
Quote:
Originally Posted by dilettante
Ive used Environ("USERNAME") several times in this app and others to get the name of the user. Im sure thats different then the class your mentioning.
It seems like with vista, Microsoft made application deployment 10x more difficult!! It used to be easy, now there's a bunch of extra steps to take... its crazy! Maybe this is just for vb6? Does .NET have these issues?
So for my program, i have the main app, a patcher app, 2 folders with images and saved files from the app, then several different config files in the app's main directory, as well as 2 files in the windows directory. Using these things you mentioned, i'll be able to install my app, and modify all the saved files and config files in the apps folder and the windows folder without problems?
The problem with environment strings is they can be changed by users to any garbage they want. But basically they'll work.
That might be asking a lot, but basically yes.Quote:
Using these things you mentioned, i'll be able to install my app, and modify all the saved files and config files in the apps folder and the windows folder without problems?
You might even be able to get VSI 1.1 to store those files in the right places during installation! If not, you'd need to install them into Programs and then on startup have your program check for them in the right location. If missing, copy them over from Programs.
BTW: Yes, .Net programmers have these same issues, which always gives me a warm chuckle since they start out feeling superior until their own programs hit the wall.
Thats exactly what my program already does. My program is a bidding program for a heating company. So there's a Proposals folder for the bids thats ever changing since new bids can be created, they can be deleted, or uploaded/downloaded from the server, there's an Images folder for the bids since they can have images attached to them, and they are printed off on page 1, so this is another ever changing folder.Quote:
Originally Posted by dilettante
In the main folder is a config file for products, presets, employees, spiffs, all kinds of things, and all the settings for the control panel (including password) are encrypted in a file in the windows folder. During install, there's a few files that have to be there, so they are included in the installation package. The rest of the files (including the files in the windows folder) are created if they dont exist when the user goes into a section where they would be used.
This is still possible with your method? It seems weird if they are since i had so many problems before! But some parts are starting to make sence.
It's not my method, Microsoft started promoting this around the time Win2K came out and was back-ported even to Win95. It's been part of "da rules" ever since but until Vista it wasn't enforced.
I'd think anything maintained for all users would go into CSIDL_COMMON_APPDATA while anything per-user should be placed into CSIDL_LOCAL_APPDATA. What's confusing?
I think the Windows folder is protected. Seems like you'd use CSIDL_COMMON_APPDATA instead.
Quote:
Originally Posted by dilettante
Whats confusing is i dont know what CSIDL_COMMON_APPDATA and CSIDL_LOCAL_APPDATA is, or how to use it, or where, or anything.. Its like some weird word(s) thats just thrown in out of nowhere that im supposed to use... but ..... how? What is it? the CSIDL_COMMON_APPDATE, isnt that the common files folder inside program files? Or are you talking about a registry entry? Am i supposed to write some info about my app and the files i need to be able to modify into some section with that name into the registry so that i can access the files i need to modify in my programs folder or the common files folder or something? You see where my confusion is at?
Well you could just go get that sample project at the link I put up there a few posts ago.
It has a Class module in it to do this, and you could just drop it into your own projects. Most of the details are spelled out in comments.
You can also read CSIDL and SHGetFolderPath Function.
Don't bother with KNOWNFOLDERID, new for Vista. You want your program to work on XP too. Also don't worry too much about "deprecated" functions for the same reason.
Quote:
Originally Posted by dilettante
Ok i'll do that. Thanks for all your help! Im going to mark this thread resolved. If i have any more questions about this i'll make a new thread for it. Thanks RobDog888 and dilettante for all the help!