Read/Write INI on Program File Vista Problem
in [Visual Basic]
|
Prev: marvendas@gmail.com Kit completo de Solenoides ( solenoid ) + chicotePara Cambio automatico 01M hidramatico Audi A3 Vw Golf gti turbo 52200
Next: Add DLL at runtime.
From: Nigel Bufton on 21 Feb 2010 06:45 The AppData folder is by far the best method because it permits per-user settings and is included in "Documents & Settings" backups and in Windows Easy Transfer. Personally, I have a dislike for programs that use Program Files - this folder is intended for files that are installed, which are easily re-creatable by re-install. Following a recent crash, I was extremely annoyed to find that a couple of apps had put all my settings in their Program Files folders. These were not on my backups - and neither should they need to be as merely reinstalling the program should recreate the content of Program Files folder as it should be. Nigel "mayayana" <mayayana(a)nospam.invalid> wrote in message news:OATcnbrsKHA.4752(a)TK2MSFTNGP04.phx.gbl... > You can save the INI files to each user's > App Data folder for individual settings. > For per-machine settings you can create > a folder under all users app data, set permissions > on it, and save settings there. > > You can also use SaveSetting > and GetSetting, which is a very easy way > to save per-user settings in the Registry > under the VB key. > > You can create a key under HKLM if you > want per-machine settings, but you'd need > to set permissions on that key in order for > people to be able to write to it. > > I do something similar to you, but for Vista+ > I changed it. I now create a folder named > Settings in the program folder during setup, > and I set that folder with permission for all. > That way I can stay inside the program folder > without affecting security because the > permissions are changed only on my own > subfolder, which contains only the settings files. > > Some people consider that approach to be "wrong" > as it's not in line with Microsoft's recommendations, > but Microsoft has made it difficult to save per-machine > settings. Personally I prefer not to be putting things > in such an obscure location as all users app data, where > nobody can find them. And per user app data is even > worse, with several folders for each person. (There > are something like 6 possible TEMP folder paths for > each user on XP+. I had to write a long script just to > perform the job of deleting TEMP files!) With the differing > folder structures on different systems, the numerous > user folders, and the problems of file virtualization, I > prefer to just keep it all clean, inside my own folders. > > > >> I have a VB6 program that reads application settings from INI file... > until >> now most users used the app on Win XP and there is big hassle running the >> program on Vista as Program File under Vista is Read Only... Under Vista >> users manually copies the INI file to Writeable directory like Documents; >> edit the INI file and then copy it back to Program Files thus rendering >> changing application settings through the VB app impossible. >> >> I would like to change program settings from INI to say egistry. But I > don't >> know how to to go about this. Can VB6 create registry keys for an app > during >> installation? I would like to create the keys for XP/Vista/Win7 >> >> I would appreciate any pointers... Thanks in advance for helping. >> >> > >
From: mayayana on 21 Feb 2010 09:42 > > Personally, I have a dislike for programs that use Program Files - this > folder is intended for files that are installed, which are easily > re-creatable by re-install. > > Following a recent crash, I was extremely annoyed to > find that a couple of > apps had put all my settings in their Program > Files folders. These were not > on my backups - and neither should they need to be Most software used to save in Program Files. A lot of software still does. (I use both Firefox and K-Meleon, for instance. They're very similar, but the former leaves settings in app data when it uninstalls -- against my wishes -- while the latter puts everything into the program folder.) I'm sure you know the history as well as I do, and you should certainly know the software that you're using, so if your backup was faulty then it can only be due to stubborn contrariness on your part. I like to use a dedicated partition for backup of various things: coding, website files, email, various program settings.... I was annoyed when I discovered that OE was storing my email in app data, under a superfluous folder named with a GUID, no less. :) But so what? That's the way it works. If I fail to backup my email because I "don't believe in using the app data folder" then there's only myself to blame.
From: Tony Toews [MVP] on 21 Feb 2010 17:22 "mayayana" <mayayana(a)nospam.invalid> wrote: >> Following a recent crash, I was extremely annoyed to >> find that a couple of >> apps had put all my settings in their Program >> Files folders. These were not >> on my backups - and neither should they need to be > > Most software used to save in Program Files. A lot of >software still does. And since Windows 2000 they shouldn't be. > I'm sure you know the history as well as I do, and you >should certainly know the software that you're using, so if >your backup was faulty then it can only be due to stubborn >contrariness on your part. No, that software that used Program Files for settings was wrong and has been wrong for ten years now. Clearly though we'll agree to disagree. 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/ Granite Fleet Manager http://www.granitefleet.com/
From: mayayana on 21 Feb 2010 18:10
> No, that software that used Program Files for settings was wrong and > has been wrong for ten years now. > > Clearly though we'll agree to disagree. > "Wrong". That's exactly the word I said some people would use. Given the corporate-culture chauvinism implied by that word, I suppose I should consider it quite gracious that you're so flexible as to "agree to disagree". :) |