Issue with wxFilePickerCtrl function SetInitialDirectory

93 views
Skip to first unread message

houchins

unread,
Aug 31, 2012, 5:26:31 PM8/31/12
to wx-u...@googlegroups.com
I am using widgets 2.9.4 on OSX with a wxFilePickerCtrl control.

When I make the call to open the picker dialog, it does not use the directory I specified via SetInitialDirectory.  Things go wrong in wxGenericFileButton::CreateDialog (below, src/generic/filepickerg.cpp lines 148-153) after the call to DoSetInitialDirectory.  The value m_path passed to SetPath (line 153) is still empty, even though my initial path is correctly set in m_initialDir:

    if ( !m_initialDir.empty() )
        DoSetInitialDirectory(dialog, m_initialDir);

    // This sets both the default file name and the default directory of the
    // dialog if m_path contains directory part.
    dialog->SetPath(m_path);

The m_path value in the dialog object has been set as a result of DoSetInitialDirectory, but the same-named variable is not set in the wxGenericFileButton object.

I came up with a patch in wxGenericFileButton::DoSetInitialDirectory that seems to work as far as setting the directory.  Not sure if this is the right or complete fix, though.

--- filepickerg-orig.cpp 2012-07-08 03:28:27.000000000 -0700
+++ filepickerg-new.cpp 2012-08-30 17:48:24.000000000 -0700
@@ -113,7 +113,7 @@
 }
 
 // ----------------------------------------------------------------------------
-// wxGenericFileutton
+// wxGenericFileButton
 // ----------------------------------------------------------------------------
 
 void
@@ -124,6 +124,7 @@
             wxString::npos )
     {
         dialog->SetDirectory(dir);
+        m_path = dialog->GetPath();  // get the dialog's new path
     }
 }

houchins

unread,
Sep 1, 2012, 2:57:01 PM9/1/12
to wx-u...@googlegroups.com

I think now that the proposed patch in my previous post wasn't quite right.  Here is one that I think works properly when the path that is passed to SetInitialDirectory includes a file name:

--- filepickerg-orig.cpp 2012-07-08 03:28:27.000000000 -0700
+++ filepickerg-new.cpp 2012-08-31 15:51:21.000000000 -0700
@@ -113,7 +113,7 @@
 }
 
 // ----------------------------------------------------------------------------
-// wxGenericFileutton
+// wxGenericFileButton
 // ----------------------------------------------------------------------------
 
 void
@@ -124,6 +124,8 @@
             wxString::npos )
     {
         dialog->SetDirectory(dir);
+        // (bugfix) prepend dialog's initial directory to the current path
+        m_path = dialog->GetDirectory() + m_path;
     }
 }

houchins

unread,
Sep 4, 2012, 3:21:38 PM9/4/12
to wx-u...@googlegroups.com

Another followup:

I have tested the widgets sample that includes a filepicker control test (2.9.4).  Without my fix, it can't seem to set an initial directory.  In the test, I select the "Save" mode radio button, Change Working dir checkbox, and set a path such as "/Applications/Audio/" via the Initial Directory button.  It doesn't work.  With my patch, the initial directory after clicking Browse show correctly.

I don't think the documentation on wxFilePickerCtrl::SetInitialDirectory is clear.  It states "Set the directory to show when starting to browse for files."  That is true if the 'dir' parameter ends in a path separator, like the example above, /Applications/Audio/.  If I leave off the ending path separator, then the final path component is treated as a file name in the picker.  Is that the intent?  It sure isn't implied by the method's name or the documentation (actually the online documentation rambles).  I like the functionality that allows me to specify a file name along with the directory, but is that a happy accident resulting from my bugfix?

Thanks.

Vadim Zeitlin

unread,
Sep 9, 2012, 9:40:12 AM9/9/12
to wx-u...@googlegroups.com
On Tue, 4 Sep 2012 12:21:38 -0700 (PDT) houchins wrote:

h> I have tested the widgets sample that includes a filepicker control test
h> (2.9.4). Without my fix, it can't seem to set an initial directory. In
h> the test, I select the "Save" mode radio button, Change Working dir
h> checkbox, and set a path such as "/Applications/Audio/" via the Initial
h> Directory button. It doesn't work. With my patch, the initial directory
h> after clicking Browse show correctly.

Thanks, I do see the problem even under Windows (which uses the same
generic implementation of this control). However I don't think the patch is
the best way to solve it. AFAICS the real fix is much simpler and at least
under MSW r72451 seems to work fine. Could you please test it under OS X?

h> I don't think the documentation on wxFilePickerCtrl::SetInitialDirectory is
h> clear. It states "Set the directory to show when starting to browse for
h> files."

This is how it's supposed to work (but doesn't currently). The idea is
that either you specify the initial path, e.g. "/Applications/Audio/foo.mp3"
and in this case you don't need this function at all as the file dialog
will open in /Applications/Audio directory anyhow. The problem this
function is meant to solve is that if you the above, this path also appears
in the text control initially which may be undesirable.

h> That is true if the 'dir' parameter ends in a path separator, like
h> the example above, /Applications/Audio/. If I leave off the ending path
h> separator, then the final path component is treated as a file name in the
h> picker. Is that the intent?

No, definitely not.

h> I like the functionality that allows me to specify a file name along
h> with the directory, but is that a happy accident resulting from my
h> bugfix?

Yes. We'd need to add SetInitialFileName() if we want to allow this.

Regards,
VZ

--
TT-Solutions: wxWidgets consultancy and technical support
http://www.tt-solutions.com/

houchins

unread,
Sep 14, 2012, 8:06:27 PM9/14/12
to wx-u...@googlegroups.com
 
 
I tested 72451 under OS X and it seems to work fine and solves the problem for my app.
 
Thanks.
 
Steve
Reply all
Reply to author
Forward
0 new messages