Selecting a locked file name in wxPython with wx.FileDialog on Windows: why it's blocked and the real solution

Learn why wx.FileDialog in wxPython on Windows rejects locked files, how FOS_SHAREAWARE in IFileDialog affects selection, and why the fix is in wxWidgets.

Selecting a file name with wx.FileDialog when the file is locked: what you can and can’t do

Sometimes you just need the path to an existing file and have no intention of opening it. With wxPython this sounds straightforward, until a different application has the file locked. On Windows, that turns a simple pick into a hard stop in the native dialog, even if you only want the name. Here’s a minimal example that reproduces the issue.

import wx

if __name__ == '__main__':
    gui = wx.App(redirect=False)
    main_win = wx.Frame(None)
    main_win.Show()

    chooser = wx.FileDialog(parent=main_win, style=wx.FD_OPEN|wx.FD_FILE_MUST_EXIST, wildcard="Project (*.ap*)|*.ap*|All files (*.*)|*.*")
    chooser.ShowModal()

    gui.MainLoop()

When the target file is in use by another program, the native dialog displays a message along the lines of “File in use. Select a different name or close the file in use in another program.” The key point is that this happens even if you don’t intend to open the file at all—you only want to select its name.

What actually causes the block

The behavior stems from how the Windows file picker handles locked files by default. wxPython delegates to wxWidgets, which in turn uses the Windows IFileDialog under the hood. The underlying implementation doesn’t enable FOS_SHAREAWARE. Without that flag, the default policy is applied and the dialog rejects files currently locked by other software. That’s exactly what you see.

Switching to other helper functions such as wx.LoadFileSelector or wx.FileSelector doesn’t change the outcome. They still flow through the same native file dialog behavior and you hit the same restriction.

Is there an application-level fix?

No. As of now this can’t be solved from wxPython code because the relevant flag isn’t set by wxWidgets. The library would need to customize the dialog by enabling FOS_SHAREAWARE to alter how locked files are treated. There was also discussion about accessing the COM object behind the dialog and toggling the flag after creation, but that’s not something you can do from wxPython. In the wxWidgets codebase there is a deliberate choice to not touch FOS_SHAREAWARE or FOS_VALIDATE, which explains the current behavior.

What would solve it

The path forward is an upstream change in wxWidgets to set FOS_SHAREAWARE for this scenario. This is feasible from an implementation standpoint, and wxWidgets is open source and accepts contributions. Once added there, the functionality becomes available to wxPython automatically.

Why this matters

File selection is a common UX pattern, and in engineering tooling it’s typical to work alongside applications that hold exclusive locks—PLCs, CAD/EDA suites, databases, and similar tools do this routinely. Understanding that the limitation comes from the native dialog’s default policy, not from your Python code, helps you avoid chasing phantom bugs or implementing convoluted workarounds that still hit the same wall.

Takeaways

If you need to pick the name of an existing, potentially locked file in wxPython, the native dialog will block selection because wxWidgets doesn’t enable FOS_SHAREAWARE. Alternative selectors in wxPython exhibit the same behavior. There isn’t a code-side workaround in application space today. If this capability is important for your workflow, the practical route is to propose or contribute a change to wxWidgets to set the appropriate flag, after which wxPython will benefit from the improvement.