Use Registry ?
in [Visual Basic]
|
From: DanS on 21 Feb 2010 08:59 I have always used INI files as a way to store program settings. This INI file was always stored in the app install directory. Would it be better to use an INI file stored in the COMMON_APP_DATA folder or just continue to use the registry via SaveSetting/GetSetting ? (This is an attempt to become UAC compliant.) TIA, DanS
From: mayayana on 21 Feb 2010 09:44 > Would it be better to use an INI file stored in the COMMON_APP_DATA folder > or just continue to use the registry via SaveSetting/GetSetting ? > > (This is an attempt to become UAC compliant.) > That's virtually the same question asked by jpBless 3 posts back.
From: DanS on 21 Feb 2010 11:07 "mayayana" <mayayana(a)nospam.invalid> wrote in news:#K$mQQwsKHA.928(a)TK2MSFTNGP04.phx.gbl: > >> Would it be better to use an INI file stored in the COMMON_APP_DATA >> folder or just continue to use the registry via >> SaveSetting/GetSetting ? >> >> (This is an attempt to become UAC compliant.) >> > > That's virtually the same question asked by jpBless > 3 posts back. Maybe, maybe not. There's a caveat in my case that I didn't mention.... (This is the IP device config program I started last month.) One of the things to be stored is the order of filenames in a sorted, wait, not a sorted, but an ordered, Listbox. These file names can be long, but I guess I'd say no one would probably type more that 50 or 60 characters, if that, but you never know. I'm expecting the user to enter a descriptive name for the file.... ie- Config for Main Street Master Radio I need to store the filenames only, and not the entire path, and this is done to just save the order in with the entries are in the Listbox. My thought is to..... 1) Retreive the names of the files from the INI or registry and enter them in the listbox in the correct order. 2) Enum each listbox entry and check to be sure the file still exists in the data dir. 3) Remove list entries of files that are no longer there. 4) Add any new files that may have not been saved in the ordered list (although there should be none if all creating/deleting is done thru the program, and not copied/pasted into the data dir thru Explorer.) So I've now got let's say 50 file names, or each averaging 30 chars. Do I......... 1) Save one long string into the registry using SaveSetting that I concatenate from the listbox entries, comma delimited. 2) Save each individual filename into the registry as it's own setting (could potentially be 100's of 'settings'). 3) Save a list in an INI file. From research, the limit to a string registry key is 64K bytes. While the easiest may be to save all filenames to one comma-delimited string, and then retreive then split, I have concerns of using such a large registry string value, even if it doesn't go over 64K bytes in size. There. A little more context to differentiate my question. TIA, DanS
From: mayayana on 21 Feb 2010 11:47 > > From research, the limit to a string registry key is 64K bytes. While the > easiest may be to save all filenames to one comma-delimited string, and > then retreive then split, I have concerns of using such a large registry > string value, even if it doesn't go over 64K bytes in size. > That does seem like an awfully lot to be putting in the Registry. But you can do it as separate values if you decide to go that way. A common method MS uses is to use 1 value for each name, then have a value that specifies the order those values should be in: value: data: 1 "file1.txt" 2 "file2.txt" 3 "file3.txt" Order "231" That way you can change the name of the file in, say, value 2 without needing to rebuild the whole Registry key. In terms of permissions, you can use GetSetting/ SaveSetting. You can use HKCU\Software\YourCompany. You can use App Data. You can use all users app data, creating a subfolder on which you've set the permissions to make it accessible.... You're talking about common app data, so presumably you want per-machine settings. (User App Data and SaveSetting are saving only for the current user.) For per-machine settings you have to set permissions somewhere because the only place where everyone has permission with UAC is the all users documents folder. So you could use HKLM\Software\YourCompany and set the permissions on that key. Or use all users app data\YourCompany and set the permissions on that folder. Those would be the 2 standard ways to do it, but whether you use a standard method/location or not, the main thing is that you'll need to set permissions. If you need code for setting permissions: I looked into this when Vista first came out. I found there are several systems for setting permissions. Some of it is fairly complex. Some people are using hokey methods like a commandline string to cacls.exe. After looking around I came up with what seems to be a relatively simple and dependable class. I use it with my installer to first check for NTFS. If the system is NTFS format I then set full permission on a program Registry key under HKLM\Software, and on program subfolders. If you want to stay "kosher" you could use it to set permissions on your own program folder under all users app data, then save settings files there. But you need to do that during install, while you're running under admin rights. http://www.jsware.net/jsware/vbcode.php5#perms
From: Tony Toews [MVP] on 21 Feb 2010 17:26
DanS <t.h.i.s.n.t.h.a.t(a)r.o.a.d.r.u.n.n.e.r.c.o.m> wrote: >I have always used INI files as a way to store program settings. This INI >file was always stored in the app install directory. > >Would it be better to use an INI file stored in the COMMON_APP_DATA folder >or just continue to use the registry via SaveSetting/GetSetting ? I'm pretty sure, but not 100% positives, that COMMON_APP_DATA isn't updatable by regular users in Windows Vista and newer. It is updatable by admins or install routines which run under admin privileges. 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/ |