I use an ini file in the app.path for a program that runs on XP. What is
considered the best practice for deciding where to save the ini file on
Vista or W7?

I read this thread which recommended this approach:

http://www.codenewsgroups.net/group/microsoft.public.vb.general.discussion/topic16789.aspx

Option Explicit
Private Declare Function SHGetSpecialFolderLocation _
   Lib "Shell32.dll" (ByVal hwndOwner As Long, _
   ByVal nFolder As Long, pidl As ITEMIDLIST) As Long
Private Declare Function SHGetPathFromIDList _
   Lib "Shell32.dll" Alias "SHGetPathFromIDListA" _
   (ByVal pidl As Long, ByVal pszPath As String) As Long
Private Type SH_ITEMID
   cb As Long
   abID As Byte
End Type
Private Type ITEMIDLIST
   mkid As SH_ITEMID
End Type
Private AppDataFolder As String
Private Const CSIDL_APPDATA = &H1A
Private Const MAX_PATH As Integer = 260

Private Function findFolder(CSIDL As Long) As String
Dim path As String, ID As ITEMIDLIST
findFolder = ""
If SHGetSpecialFolderLocation(Me.hWnd, CSIDL, ID) = 0 Then
path = Space$(MAX_PATH)
If SHGetPathFromIDList(ByVal ID.mkid.cb, ByVal path) Then
   findFolder = Left$(path, InStr(path, Chr(0)) - 1) & "\"
End If
End If
End Function

Private Sub Form_Load()
AppDataFolder = findFolder(CSIDL_APPDATA)
Caption = AppDataFolder
End Sub

Is it considered good practice to detect the OS, leave the ini in the
app.path for XP, and use that approach for Vista or W7? And if I do use
that approach is it true that I won't run into any permissions problems?

I'd like to write this into the program now so it doesn't matter what OS
it's run on.

Thanks,
Mike

Leave it in the app datapath for Win 2000 and up.  They should have been
there all along.

http://www.codenewsgroups.net/group/microsoft.public.vb.general.discussion/topic16789.aspx
Show quoteHide quote

On 8/5/2010 9:03 PM, Kevin Provance wrote:
Sounds good, very easy fix.

Thanks,
Mike

  You realize that's a per-user method and what
you were doing is a per-machine method? You
can also just use the VB SaveSetting/GetSetting
functions if it's per-user. Those are designed to
mimic INI files. But if you need it per-machine
you need to take a different approach and change
permissions somewhere.

What mimicry are you referring to?  For VB4 16 bit, they read/wrote to
actual .ini files.  For 32 bit VB, they read/write the Registry;
specifically, to subkeys under "HKEY_CURRENT_USER\Software\VB and VBA
Program Settings".

I cannot agree with that at all.  A program has no business changing
permissions just to satisfy its own shortcomings (i.e. bad programming).

  I understand that. I just meant that the way the
methods work is designed in a similar way to the
INI APIs: Saving string data by grouping and value
(*PrivateProfileString), returning all values in a
grouping (*PrivateProfileSection), etc.
The OP is using INIs, so I thought the VB methods
might be a reasonable substitute.

   I know that several people here have an odd
knee-jerk reaction about that issue. I'm speaking
for everybody else.

  Your approach is designed for use with corporate
employees who have no rights to the PC they use
and need per-user settings. That's fine. App data
is good for that. In a SOHo environment it often
works differently. Per-machine settings often make
sense. Also, people own their PCs. It's a matter of
common courtesy to be as transparent as possible
with software installed, not hiding program files off in
a bizarre, convoluted hierarchy of user folders where
the average person cannot find them. Many people
will never know or care about those files, but that's
not for us to decide. They should have access to the
files if they want it. People shouldn't need to be expert
tweakers just to figure out where the files for my
software are stored.

  (The first time I discovered that the app data method
was being used was with Firefox, when I installed a new
version and found that all my old settings were still there.
After using Filemon/Regmon to figure out what was going
on I was amazed that Mozilla had seen fit to take that
liberty -- storing all that stuff on my system when the
software was uninstalled -- without asking me. That's what
I'd call bad programming practice.)

  If you want all people to be reading/writing to settings
then they have to be public. The popular way to do that
seems to be using a company subfolder under all users
app data. Personally I create a folder under app.path,
set permissions r/w for all users during install, and then
just store settings files in there. It's clean and easy. It's
safe. I'm not messing with any public folders. And it's
all gone when my software is uninstalled. But however you
do it, there has to be a restriction-free folder somewhere.

  The whole point here is to serve the needs of the end-user.
Part of that is transparency. Part convenience. And of course
there should be a healthy respect for security issues. But
I think there's a tendency to get carried away with the letter
of the law and to forget the spirit. The app data folder is
Microsoft's "best practice" recommendation because Microsoft
does not acknowledge the SOHo scenario. Despite selling 2/3
of their PCs to non-corporate customers, WinNT is basically
a corporate workstation OS. (Even the so-called "Home" version.)
The same problem happens on Linux. Most of the people who
are doing professional programming are doing it for corporate
customers.

  So while you or Kevin will answer a query by saying
"put it in app data where it belongs", I'm trying to
provide an answer that will help the questioner to
understand the whole situation. Then they can make
their own decision.

On 8/6/2010 4:32 AM, Mayayana wrote:
Per-user will work perfectly, thanks for pointing that out.

Thanks Again,
Mike

On Thu, 05 Aug 2010 20:40:07 -0700, Mike S <ms***@yahoo.com> wrote:

¤ I use an ini file in the app.path for a program that runs on XP. What is
¤ considered the best practice for deciding where to save the ini file on
¤ Vista or W7?
¤
¤ I read this thread which recommended this approach:
¤
¤ http://www.codenewsgroups.net/group/microsoft.public.vb.general.discussion/topic16789.aspx

Yes, get it out of the application path and into APPDATA. Relying on the virtualization mechanism
can get you into trouble if you put a data file into the system area.


Paul
~~~~
Microsoft MVP (Visual Basic)

Actually, it's not fine on XP or even Windows 2000, although it seems to
work fine. That's because most developers are logged in as Administrators.
In Vista+, you are treated as a member of the limited "Users" group even if
you are an Admin, unless you turn off UAC, or use "Run As Administrator".
So, if you left the INI in App.Path, a member of the "Users" group would
complain that the settings are not saved in 2000/XP/2003 Server, and no
problem in Vista and after(Because in Vista+, INI files that are left in
Program Files are redirected to a per user location).

If you want your settings per user, then use CSIDL_APPDATA, or
GetSetting/SaveSetting.

If you want per machine settings, use CSIDL_COMMON_APPDATA, but you also
need to change the permissions on your subfolder to allow all users to write
to the folder.

Nobody wrote:
Show quoteHide quoteI'm reluctant to use the registry because I don't know anything about
how the various versions of Vista or W7 will handle permissions. Do you
know if it is the case that a VB6 program running under those OS's as an
Admin, or as a user with limited rights, in any mode available, will
always be able to write to the registry with no problems? I want the
simplest solutions that will require the least maintenance and run on
any version of XP or later, so I'm using CSIDL_APPDATA. This program
will be run by only one user on any given machine, and speed is not an
issue (I think registry reading is probably a lot faster than INI
reading) so I just want to keep this as robust an approach as possible.

Mike

Show quote Hide quote Here is a guideline to work by:

Always assume your app runs without Admin priv (most don't quire it anyway)
and remember your rules as such.  In regard to the registry, you can READ
anywhere you want.  Writing is only appropriate to HKCU.  Everything else is
and should be off limits.

Like Kevin said, only HKCU is writable in the registry, and each user has
his own copy. HKLM is read only. GetSetting/SaveSetting use HKCU, so they
are okay to use. If you have a lot of settings, more than 2 KB, then perhaps
an INI file is more appropriate. More than 64KB, and you need something
other than INI files. One issue that you might have with
GetSetting/SaveSetting is that they always save and read strings. If someone
created a DWORD or binary value, you get Error 5, Invalid procedure call or
argument. This happens if a user added a value by using RegEdit for example.

On 8/8/2010 5:05 PM, Nobody wrote:
Show quoteHide quoteThanks Kevin, and thank you Nobody for the detailed explanation.

Get Selected Path From Explorer
How to save a picturebox's image to a .PNG file? (VB6)
Unicode API
System Timer Callback?
Form Z order across the divide
Old VB Project doesn't work with New Office or Windows 7
Reconnection issue between Winsock Server(VB6) and TCP Client (VB.NET)
Instantiation
Any thoughts? Application error .data not place into memory because of an I/O error
Are PDB files used by VB6