wx.FileDialog Help

Hi, I'm new to wxPython, so please bear with me.

I'm currently using a wx.FileDialog to open/look at some files.
I've been looking for a (relatively easy) way to change the label on the 'Open'
Button to something more appropriate for my application.

I've looked everywhere, but found nothing. Am I missing something really
obvious, or is it even possible?

Thanks in advance,
Brad

···

----------------------------------------
This mail sent through www.mywaterloo.ca

Brad Van Vugt wrote:

Hi, I'm new to wxPython, so please bear with me.

I'm currently using a wx.FileDialog to open/look at some files. I've been looking for a (relatively easy) way to change the label on the 'Open'
Button to something more appropriate for my application.

I've looked everywhere, but found nothing. Am I missing something really
obvious, or is it even possible?

The common dialogs on windows (and some of them on other platforms too) are just wrappers around a platform API function and so we are limited to what they can offer via the funciton interface. For wx.FileDialog we are limited to a wx.OPEN or wx.SAVE style, you can't modify the look or behaviour beyond that.

···

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!

Not really a wxPython question, but there any Python Modules with functions that
will return the local path to the 'My Documents' on Windows machines?

Thanks,
Brad

···

----------------------------------------
This mail sent through www.mywaterloo.ca

try os.getenv("USERPROFILE") on Windows and os.getenv("HOME") on Mac OS/X.
At least, that's what seems to work for me.

David

···

-----Original Message-----
From: Brad Van Vugt [mailto:bvanvugt@student.cs.uwaterloo.ca]
Sent: Thursday, September 30, 2004 1:02 PM
To: wxPython-users@lists.wxwidgets.org
Subject: [wxPython-users] My Documents Directory

Not really a wxPython question, but there any Python Modules with
functions that
will return the local path to the 'My Documents' on Windows machines?

Thanks,
Brad

----------------------------------------
This mail sent through www.mywaterloo.ca

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

Okay, I'm wrong. os.getenv("USERPROFILE") + os.sep + 'My Documents' gets
you where My Documents will be if the user hasn't moved it, but if they
have, it doesn't work. Sorry about that. I don't know the answer.

David

···

-----Original Message-----
From: David Woods [mailto:dwoods@wcer.wisc.edu]
Sent: Thursday, September 30, 2004 1:14 PM
To: wxPython-users@lists.wxwidgets.org
Subject: RE: [wxPython-users] My Documents Directory

try os.getenv("USERPROFILE") on Windows and os.getenv("HOME") on Mac OS/X.
At least, that's what seems to work for me.

David

> -----Original Message-----
> From: Brad Van Vugt [mailto:bvanvugt@student.cs.uwaterloo.ca]
> Sent: Thursday, September 30, 2004 1:02 PM
> To: wxPython-users@lists.wxwidgets.org
> Subject: [wxPython-users] My Documents Directory
>
>
> Not really a wxPython question, but there any Python Modules with
> functions that
> will return the local path to the 'My Documents' on Windows machines?
>
> Thanks,
> Brad
>
> ----------------------------------------
> This mail sent through www.mywaterloo.ca
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: wxPython-users-unsubscribe@lists.wxwidgets.org
> For additional commands, e-mail: wxPython-users-help@lists.wxwidgets.org
>
>

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

David Woods wrote:

Okay, I'm wrong. os.getenv("USERPROFILE") + os.sep + 'My Documents' gets
you where My Documents will be if the user hasn't moved it, but if they
have, it doesn't work. Sorry about that. I don't know the answer.

Also, if it's not an english version of Windows then it won't be spelled "My Documents" even if it is in the USERPROFILE location. The proper way to find it is to get the value from the registry, but I don't know the location off the top of my head...

···

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!

http://groups.google.ca/groups?hl=en&lr=&ie=UTF-8&threadm=mailman.1055180657.24663.python-list%40python.org&rnum=1&prev=/groups%3Fq%3Dregistry%2Bapplication%2Bdata%2Bmcfletch%26hl%3Den%26lr%3D%26ie%3DUTF-8%26selm%3Dmailman.1055180657.24663.python-list%2540python.org%26rnum%3D1
http://groups.google.ca/groups?hl=en&lr=&ie=UTF-8&threadm=mailman.1140.1075749926.12720.python-list%40python.org&rnum=2&prev=/groups%3Fq%3Dregistry%2Bapplication%2Bdata%2Bmcfletch%26hl%3Den%26lr%3D%26ie%3DUTF-8%26selm%3Dmailman.1140.1075749926.12720.python-list%2540python.org%26rnum%3D2

Have fun,
Mike

Robin Dunn wrote:

···

David Woods wrote:

Okay, I'm wrong. os.getenv("USERPROFILE") + os.sep + 'My Documents' gets
you where My Documents will be if the user hasn't moved it, but if they
have, it doesn't work. Sorry about that. I don't know the answer.

Also, if it's not an english version of Windows then it won't be spelled "My Documents" even if it is in the USERPROFILE location. The proper way to find it is to get the value from the registry, but I don't know the location off the top of my head...

________________________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder
  http://www.vrplumber.com
  http://blog.vrplumber.com

Mike C. Fletcher wrote:

[Some long Google groups URLS]

Robin Dunn wrote:

Also, if it's not an english version of Windows then it won't be
spelled "My Documents" even if it is in the USERPROFILE location. The proper way to find it is to get the value from the registry, but
I don't know the location off the top of my head...

There is only one correct way to get the path, and using environment
variables is not correct, nor is using the registry. The amusing
history behind that is at:

http://weblogs.asp.net/oldnewthing/archive/2003/11/03/55532.aspx

The correct value can be gotten by doing the following with
win32all installed:

     from win32com.shell import shell, shellcon
     path=shell.SHGetFolderPath(0, shellcon.CSIDL_PERSONAL, None, 0)

If you also intend to use py2exe on your application then I found the
following code necessary to get the relevant modules found. Place
in your setup.py:

# See http://starship.python.net/crew/theller/moin.cgi/WinShell
import modulefinder
import win32com
for p in win32com.__path__[1:]:
    modulefinder.AddPackagePath("win32com", p)
for extra in ["win32com.shell"]:
    __import__(extra)
    m=sys.modules[extra]
    for p in m.__path__[1:]:
        modulefinder.AddPackagePath(extra, p)

Roger

Roger Binns wrote:
...

Robin Dunn wrote:

Also, if it's not an english version of Windows then it won't be
spelled "My Documents" even if it is in the USERPROFILE location. The proper way to find it is to get the value from the registry, but
I don't know the location off the top of my head...

There is only one correct way to get the path, and using environment
variables is not correct, nor is using the registry. The amusing
history behind that is at:

Correct, way to get it, true. Available with core Python, no :wink: :slight_smile: .

Still, good to read the logic laid out in full as a history.

For applications programmers, it's fine to say 'well, I'll include win32all in my application' for doing this, but library programmers need to be able to deal with a missing dependency (especially when the dependency is such a large package and would only be used for this one function). You'll note that the OpenGLContext module uses the correct method *if possible*, and only degrades to using the registry if the shell-folder functions aren't available.

The proper way to deal with this, of course, is, I suppose, something similar to the _winreg module in Python, i.e. a very small DLL that provides just the "get shell folder" functions (but have one for all platforms). Until that happens, I'd be inclined to have the backup code available. After all, if it fails, you're no worse off than before (since you don't have the shell functions, and much as they whine about it :wink: , Microsoft will continue to support those common registry entries because their bread-and-butter is backwards compatibility), but if it succeeds, your library can continue to function as expected. Yes, yes, I know "refuse the temptation to guess", but "practicality beats purity".

Though come to think of it, OpenGLContext could probably use even more guarding for cases where _winreg is available but not the keys (thanks for reminding me about that). Maybe could use a ctypes version of the shell-folder code as well, just to provide "opportunistic" success as much as possible.

Enjoy yourselves,
Mike

···

________________________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder
  http://www.vrplumber.com
  http://blog.vrplumber.com

Mike C. Fletcher wrote:

platforms). Until that happens, I'd be inclined to have the backup
code available. After all, if it fails, you're no worse off than
before (since you don't have the shell functions, and much as they
whine about it :wink: , Microsoft will continue to support those common
registry entries because their bread-and-butter is backwards
compatibility),

If you read all the comments attached to Raymond's article, you'll
see how he mentions some stuff changing for Longhorn, and additional
registry keys etc.

The real question each developer needing this functionality needs to
ask is if they are prepared to get a wrong or non-existent answer
if not using the "correct" way.

I have slowly come round to believing that win32all should just be
considered an essential Python library. With one exception, I have
never written a Python program (including cross platform ones) that
didn't use win32all for something :slight_smile:

Roger

"Mike C. Fletcher" <mcfletch@rogers.com> writes:

Roger Binns wrote:
...

Robin Dunn wrote:

Also, if it's not an english version of Windows then it won't be
spelled "My Documents" even if it is in the USERPROFILE
location. The proper way to find it is to get the value from the
registry, but
I don't know the location off the top of my head...

There is only one correct way to get the path, and using environment
variables is not correct, nor is using the registry. The amusing
history behind that is at:

Correct, way to get it, true. Available with core Python, no :wink: :slight_smile: .

Still, good to read the logic laid out in full as a history.

For applications programmers, it's fine to say 'well, I'll include
win32all in my application' for doing this, but library programmers
need to be able to deal with a missing dependency (especially when the
dependency is such a large package and would only be used for this one
function). You'll note that the OpenGLContext module uses the correct
method *if possible*, and only degrades to using the registry if the
shell-folder functions aren't available.

The proper way to deal with this, of course, is, I suppose, something
similar to the _winreg module in Python, i.e. a very small DLL that
provides just the "get shell folder" functions (but have one for all
platforms).

As you probably already know, I suppose, ctypes is such a small dll,
although it could be used to replace (rewrite, really) _winreg.pyd as
well. Sorry for the plug :wink:

THOMAS

What's that sound? Do I hear a PEP being written? :wink:

ka

···

On Oct 5, 2004, at 2:13 AM, Thomas Heller wrote:

"Mike C. Fletcher" <mcfletch@rogers.com> writes:

Roger Binns wrote:
...

Robin Dunn wrote:

Also, if it's not an english version of Windows then it won't be
spelled "My Documents" even if it is in the USERPROFILE
location. The proper way to find it is to get the value from the
registry, but
I don't know the location off the top of my head...

There is only one correct way to get the path, and using environment
variables is not correct, nor is using the registry. The amusing
history behind that is at:

Correct, way to get it, true. Available with core Python, no :wink: :slight_smile: .

Still, good to read the logic laid out in full as a history.

For applications programmers, it's fine to say 'well, I'll include
win32all in my application' for doing this, but library programmers
need to be able to deal with a missing dependency (especially when the
dependency is such a large package and would only be used for this one
function). You'll note that the OpenGLContext module uses the correct
method *if possible*, and only degrades to using the registry if the
shell-folder functions aren't available.

The proper way to deal with this, of course, is, I suppose, something
similar to the _winreg module in Python, i.e. a very small DLL that
provides just the "get shell folder" functions (but have one for all
platforms).

As you probably already know, I suppose, ctypes is such a small dll,
although it could be used to replace (rewrite, really) _winreg.pyd as
well. Sorry for the plug :wink:

THOMAS

[getting the path of the 'My Documents' directory on Windows]

For applications programmers, it's fine to say 'well, I'll include
win32all in my application' for doing this, but library programmers
need to be able to deal with a missing dependency (especially when the
dependency is such a large package and would only be used for this one
function). You'll note that the OpenGLContext module uses the correct
method *if possible*, and only degrades to using the registry if the
shell-folder functions aren't available.

The proper way to deal with this, of course, is, I suppose, something
similar to the _winreg module in Python, i.e. a very small DLL that
provides just the "get shell folder" functions (but have one for all
platforms).

As you probably already know, I suppose, ctypes is such a small dll,
although it could be used to replace (rewrite, really) _winreg.pyd as
well. Sorry for the plug :wink:

What's that sound? Do I hear a PEP being written? :wink:

AFAIK, PEP's are not required for additions to the standard library.

Dave Brueck once suggested to include ctypes with Python:

http://mail.python.org/pipermail/python-dev/2004-January/041814.html

but finally Guido didn't like it, because it would be too easy to crash
Python with it:

http://mail.python.org/pipermail/python-dev/2004-January/041856.html

Thomas