wxFileDialog::GetDirectory doesn't return the user-selected path

[obfuscated]

This bug is similar to ticket #14525 and the problem seems the same.

The problem happens in both 2.9 and 2.8 svn heads.

[vadz]

It should be then fixed in the similar way, i.e. by remembering the directory in the dialog itself before it's dismissed. If you can do it and submit a patch with your changes, it would be great.

[obfuscated]

Something like this (see the attached patch)?

[vadz]

Looks fine for me, if it works for you then it must be correct, thanks!

[VZ]

(In [72979]) Fix path returned from wxGTK wxFileDialog too.

This is similar to the fixes to wxDirDialog in r72779.

Closes #14786.

[obfuscated]

patch for wx2.8

[obfuscated]

Just added a patch for wx2.8. Seems a little simpler, maybe the m_dir should be reused in 2.9, too.

[vadz]

Should be OK to apply for 2.8.13 if anybody decides to make it.

I think the code in the trunk is clear enough so I don't see any particular need to change it...

[obfuscated]

I suppose these two bugs will require new release of 2.8, because they are extremely annoying, when using recent distros and also not all packages have migrated to 2.9

[PC]

(In [73089]) Fix path returned from wxFileDialog, closes #14786

[vadz]

I'm going to replace the patch applied in r72979 with the simpler patch for 2.8 applied in r73089 because it turns out that we must generate the fake wxEVT_BUTTON_CLICKED event in wxFileDialog code as the native GTK+ wxFilePickerCtrl relies on it and the change in the trunk broke it, see #15218.

Please retest your code with the new fix and reopen the bug if it doesn't work. TIA!

[VZ]

(In [74043]) Fix regression in wxGTK wxFilePickerCtrl due to wxFileDialog changes.

Revert the changes of r72979 and fix wxFileDialog::GetDirectory() return
value bug (see #14786) differently to avoid breaking wxFilePickerCtrl which
relies on getting wxEVT_BUTTON event when the associated dialog is dismissed.

Closes #15218.