How does wxFileDialog remember the directory?

[mbeardsley]

When running a program that uses a wxFileDialog, the dialog seems to somehow "remember" the directory accessed most recently, and uses that directory as the new "current" location.

Furthermore, it remembers this even after the program is shut down and restarted. While this is a pretty cool "feature", I need to know how this is accomplished (is it written into the registry, or stored in the AppData directory, or something else?).

I have looked around for where it might be stored but haven't found anything useful.

[ONEEYEMAN]

Hi,
What seems to be the problem? Do you NOT want it to happen?
How do you create the dialog?

Thank you.

[doublemax]

Assuming you're under Windows, the OS does that.

[mbeardsley]

Yes, this is under Windows.

The problem is that we have a government customer that needs to know if/how/when our software modifies the registry, and "maybe" is not an answer that they will accept.

So, is the "last used directory" stored in the registry somewhere (I haven't been able to find it), or somewhere else?

[PB]

wxWidgets uses Get{Open|Save}FileName() to display its wxFileDialog. On Vista+ and when wxFileDialog has no custom control, Windows display IFileDialog-based dialog. This dialog has a folder persistence briefly described in State Persistence section:
https://docs.microsoft.com/en-us/window ... ersistence

However, please keep in mind that IFileDialog's ClearClientData() or SetClientGuid() cannot even be called from wxWidgets because as described above, wxWidgets does not use IFileDialog directly for wxFileDialog (it does for wxDirDialog) but it uses the legacy Get*FileName() function.

A bit of Googling revelead, and my brief regedit session seems to confirm, that the remembered paths are stored in
Computer\HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\ComDlg32\
and the subkey depends on the API used/dialog displayed.

I found my recent path used by wxFileDialog by extension in the OpenSavePidlMRU key.

The paths are stored as REG_BINARY (UTF16-encoded?), so that is why a simple regedit string search will not find them.

EDIT
You can try this tool to view the data in the human readable form
https://www.nirsoft.net/utils/open_save_files_view.html
to try to see if yours are there.

[mbeardsley]

Thank you, that info is very useful.