Application path

1) has already been commented
2) wxConfig is platform dependent. Why not using the module ConfigParser?
It is a pure Python module and therefore platform independent. I

appreciate

the # for commenting a line.

Depends what you mean. wxConfig (actually, wxConfigBase) is actually
platform *independent*. It creates the correct config format for your
platform, but the *operations* you do (define a variable, a hierarchy, etc)
are *independent* of platform. You don't need to know and shouldn't care
that on Windows the commands are actually done on the Registry whereas on
Unix they act on (e.g.) the HOME/.something file.

There are two serious limitations with ConfigParser, AFAICT:
1) does not support hierarchy, only "blocks"
2) requires a directory to be stored in, which on Windows can be annoying
since there is no concept of "HOME" unless you've defined the HOME
environment variable, which almost no one does.

Oliver

There are two serious limitations with ConfigParser, AFAICT:
1) does not support hierarchy, only "blocks"
2) requires a directory to be stored in, which on Windows can be annoying
since there is no concept of "HOME" unless you've defined the HOME
environment variable, which almost no one does.

Actually, Windows (meaning windows NT,2000, XP or 2003 and purposefully
excluding the older Win9x variants) DO have something like "home". They are
called user profiles, and denote a directory where user specific data is
stored.

The corresponding path is stored in the environment variable %USERPROFILE%
when a user logs on to the system, and it is specific to that user's login
session, of course (not system-wide), since there can be multiple users
logged in on a machine (even on workstations, e.g. using telnet).

Eddy Buhler

Eddy Buhler wrote:

There are two serious limitations with ConfigParser, AFAICT:
1) does not support hierarchy, only "blocks"
2) requires a directory to be stored in, which on Windows can be annoying
since there is no concept of "HOME" unless you've defined the HOME
environment variable, which almost no one does.
   
Actually, Windows (meaning windows NT,2000, XP or 2003 and purposefully
excluding the older Win9x variants) DO have something like "home". They are
called user profiles, and denote a directory where user specific data is
stored.

The corresponding path is stored in the environment variable %USERPROFILE%
when a user logs on to the system, and it is specific to that user's login
session, of course (not system-wide), since there can be multiple users
logged in on a machine (even on workstations, e.g. using telnet).

Just what I was thinking ... does the current wxWidgets code use this information or not?
If not, then that would be a worthwhile enhancement...

David

Hi,

David Fraser wrote:

Just what I was thinking ... does the current wxWidgets code use this information or not?
If not, then that would be a worthwhile enhancement...

wxWidgets uses this information.
I use a wx.FileConfig (I hate the registry) in my app
and the file is created in my USERPROFILE directory.

Here is the code I use to create the file config.
     ini_filename = self.GetAppName().lower() + '.ini'
     self.conf = wx.FileConfig( localFilename=ini_filename)
     self.conf.SetRecordDefaults(True)
     wx.ConfigBase_Set(self.conf)

one important thing about this, is that you need to keep
a reference to the config object yourself.
wx.ConfigBase_Set() doesn't seem to increment the ref count on the
object.

Regards
    Adi

David Fraser wrote:

Eddy Buhler wrote:

...

The corresponding path is stored in the environment variable %USERPROFILE%
when a user logs on to the system, and it is specific to that user's login
session, of course (not system-wide), since there can be multiple users
logged in on a machine (even on workstations, e.g. using telnet).

Generally speaking, code should use the registry shell directories. Relying on environmental variables is way too fragile on windows (especially as the one variable used there only points to the profile directory, and there are a half dozen or so special folders for which certain configurations may change the location). On, for instance, my old win98 laptop, there's no USERPROFILE variable set.

Is the OpenGLContext module which retrieves the user's AppData shell path, which is normally a sub-directory of their profile (though AFAIK it can change with roaming profiles) in which you should create an app-specific directory and store your user's disk-based data and settings.

That works on Win2k and Win98 (I don't have win95 or XP for testing), and is doing it the "right" way as much as possible.

$0.02CDN,
Mike

···

________________________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder
  http://members.rogers.com/mcfletch/
  blog: http://zope.vex.net/~mcfletch/plumbing/

Win9y doesn't really support different user profiles, is why I explicitly
excluded them from the list.

Windows NT derivatives (NT, Win 2000, XP, 2003 etc.) are "real" multi-user
systems in that there is a directory for storing user settings. If e.g. on a
Windows 2000 workstation you have three users hank, frank, and kixter, there
will be some directory like "c:\user settings" (in German, it is
"c:\dokumente und einstellungen") where you will find a subdirectory for
each user name, storing the personal data for that user.

while there ARE in fact in each of those user-specific directories a number
of further subdirs, such as for lots of microsoft stuff, they ARE usable.
Besides, on a Windows 2000 machine, you'd have to explicitly unset the
%userprofile% variable, or disable it by some kind of system policy (not
even sure if it's anything that would be easy to do) to make it not work
there.

But then, on Unix you could do just the same. If you want to break it, and
you have the administrative rights to mess up your system, you can. The only
reason I am writing this is that environment variables are no more and no
less "fragile" on Windows than on Unix (again, purposefully excluding the
older Win9x variants).

However, my point was simply to state that the more robust NT kernel based
Windows systems DO know something like home for a user, and answer the
question brought up regarding that topic.

If the solution you quoted for determining a good place to store app data
works well on all windows platforms and for multiple users, then by all
means use it. :slight_smile:

Eddy Buhler

···

-------------------------
There are two rules to success in life. Rule one: Don't tell people
everything you know.

----- Original Message -----
From: "Mike C. Fletcher" <mcfletch@rogers.com>
To: <wxPython-users@lists.wxwidgets.org>
Sent: Thursday, May 20, 2004 9:17 PM
Subject: Re: [wxPython-users] Application path

David Fraser wrote:

> Eddy Buhler wrote:

...

>> The corresponding path is stored in the environment variable
>> %USERPROFILE%
>> when a user logs on to the system, and it is specific to that user's
>> login
>> session, of course (not system-wide), since there can be multiple users
>> logged in on a machine (even on workstations, e.g. using telnet).
>
Generally speaking, code should use the registry shell directories.
Relying on environmental variables is way too fragile on windows
(especially as the one variable used there only points to the profile
directory, and there are a half dozen or so special folders for which
certain configurations may change the location). On, for instance, my
old win98 laptop, there's no USERPROFILE variable set.

Is the OpenGLContext module which retrieves the user's AppData shell
path, which is normally a sub-directory of their profile (though AFAIK
it can change with roaming profiles) in which you should create an
app-specific directory and store your user's disk-based data and settings.

That works on Win2k and Win98 (I don't have win95 or XP for testing),
and is doing it the "right" way as much as possible.

$0.02CDN,
Mike

________________________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder
  http://members.rogers.com/mcfletch/
  blog: http://zope.vex.net/~mcfletch/plumbing/

---------------------------------------------------------------------
To unsubscribe, e-mail: wxPython-users-unsubscribe@lists.wxwidgets.org
For additional commands, e-mail: wxPython-users-help@lists.wxwidgets.org

Adi Sieker wrote:

Hi,

David Fraser wrote:

Just what I was thinking ... does the current wxWidgets code use this information or not?
If not, then that would be a worthwhile enhancement...

wxWidgets uses this information.
I use a wx.FileConfig (I hate the registry) in my app
and the file is created in my USERPROFILE directory.

Here is the code I use to create the file config.
    ini_filename = self.GetAppName().lower() + '.ini'
    self.conf = wx.FileConfig( localFilename=ini_filename)
    self.conf.SetRecordDefaults(True)
    wx.ConfigBase_Set(self.conf)

one important thing about this, is that you need to keep
a reference to the config object yourself.
wx.ConfigBase_Set() doesn't seem to increment the ref count on the
object.

Regards
   Adi

Thanks, I looked at the code but couldn't work it out... worthwhile to know

David