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/