Portable File Dialogs not working on Windows in v1.5.2 but did work in v1.3, v1.52 does work on MacOS

[west-rynes]

trafficstars

python version: 3.11.9

If I run the below code on my windows machine, when I click the open file button it just hangs and then the app crashes. No diagnostic info is printed on the terminal. However, the same code works on MacOS. If I downgrade to v1.3 then it works on Windows.

from imgui_bundle import imgui, immapp
from imgui_bundle import portable_file_dialogs as pfd


def gui():
    imgui.text("Sample App")
    
    if imgui.button("open file"):
        dlg = pfd.open_file("File Dialog")
        res = dlg.result()


def run_app():

    immapp.run(
        gui_function=gui,  
        window_title="Hello!",  
        window_size_auto=True,  
    )


if __name__ == "__main__":
    run_app()

[pthom]

Hello Anthony,

Many thanks for your email, I will answer you in the following days (and I also have another new promising project which I would like you to look at).

Your code does not fail on my windows machine. As a matter of fact, I did not upgrade Portable File Dialog between those versions. This is strange.

Could you try to provide an alternative default folder, e.g.

    dlg = pfd.open_file("File Dialog", "c:\\") 

[west-rynes]

I thought that was an excellent idea, I tried putting a few different default paths as above, but still the same result. It just hangs. Would you have any idea as to how I could diagnose it?

It is so strange, it all works on v 1.3. The only change is I just pip upgrade between the two versions of imgui_bundle and re-run.

[pthom]

Since it is working on my Windows Machine, could you try on another computer so that we can see whether it is related to a machine configuration?

---

In order to debug further it would be required to compile from source, and try to debug on the C++ side. The pybind_native_debug program enables to debug the C++ code when it is called from Python.

The principle is easy by using pybind_native_debug which I provide (however, setting this up under windows is tricky)

1. Change the content of pybind_native_debug/pybind_native_debug.py (put your script inside)
2. Run the C++ program pybind_native_debug, place a breakpoint inside the C++ code of "portable_file_dialog", and debug on the C++ side.

---

However under Windows setting it up is very complex : it does require a lot of manual path adjustments (as well as fiddling with DLL paths, using old utilities such as depends)

 For example I had to

1. Adjust your script to add paths, like this

import sys

# Manual path adjustments (we have to make sure all dll can be found, which is quite a troublesome experiences under windows)
sys.path.append("F:/dvp/_Bundle/imgui_bundle/bindings")
sys.path.append("F:/dvp/_Bundle/imgui_bundle/builds/python/Debug")
sys.path.append("F:/dvp/_Bundle/imgui_bundle/venv_x64/Lib/site-packages")
sys.path.append("F:/Utils/Python311-amd64/DLLs")

# Explicitly load the DLL
import ctypes
ctypes.CDLL("F:/dvp/_Bundle/imgui_bundle/bindings/imgui_bundle/glfw3.dll")


from imgui_bundle import imgui, immapp
from imgui_bundle import portable_file_dialogs as pfd


def gui():
    imgui.text("Sample App")
    
    if imgui.button("open file"):
        dlg = pfd.open_file("File Dialog")
        res = dlg.result()


def run_app():

    immapp.run(
        gui_function=gui,  
        window_title="Hello!",  
        window_size_auto=True,  
    )


if __name__ == "__main__":
    run_app()

2. make sure python311.dll and glfw3.dll are in the PATH
3. download the opencv world 4.10.0 debug dll from https://opencv.org/releases/ , and make sure it is in the PATH

[west-rynes]

Thank you so much for all the helpful instructions. You are too kind to write all that out.

Yes - I will first find another windows system to test on. My secondary one is still not fixed from the darn CrowdStrike software fiasco… but I’ll just find a coworker who can run it. Otherwise I’ll see if I can debug in my end with your instructions. If anything I can always add print statements in the PFF C++ code and figure out where exactly it fails.

Sorry to trouble you especially if it is just an issue on my end

[pthom]

My secondary one is still not fixed from the darn CrowdStrike software fiasco…

Oh, no!! Good luck :-)

[west-rynes]

So I was able to get 2 of the student interns working with me to test it out on windows and they had the same issue of it hanging when clicking the button to launch the PFD file dialog with version v1.5.2. But v1.3 works for them.

One student is running Windows 11 with python 3.12.4 The other student is running Windows 11 with python 3.11.5

If only everyone would just get a Mac, life is so much easier in my opinion. And I am constantly amazed how fast the silicon Mac laptops are compared to supposedly top end windows desktop towers. My life sure would be easier deploying these apps....

[west-rynes]

I will see if I can get a bit of time to try out your debugging instructions. Although I'm not quite the wizard you are but it will be good learning for myself.

[pthom]

So I was able to get 2 of the student interns working with me to test it out on windows and they had the same issue of it hanging when clicking the button to launch the PFD file dialog with version v1.5.2. But v1.3 works for them.

Hum. I will try to reproduce it here on a different machine also

[pthom]

Ouch, ouch, ouch!

I'm pretty sure we are hitting an issue with the Windows Github runner/ builders. The wheels that are compiled with them are broken. If I compile the wheel on my side it works perfectly, However, if I use the wheels that are produced on GitHub, it does fail.

I recently experienced a similar issue where they had not correctly updated Windows SDK runtimes, and durably broke thousands of CI builds on various projects. I'm beginning to distrust GitHub's windows runners deployment strategy. This time it is even worse because it now fails at runtime (not build time). I don't know where to begin if I want to be able to submit an issue to GitHub so that they can work on it.

It is very likely that you will not be able to reproduce the issue if you recompile on your side.

---

What bothers me is that I know that I will have to publish a new version, where I will be forced to manually compile the windows wheels for each Python version.

In the meantime, I'm going to try to enjoy Paris in this Olympic summer this afternoon.

Can you please try to install one of these wheels which I did compile manually (for python 3.11 and 3.12)

http://traineq.org/imgui_bundle-1.5.2-cp311-cp312-win_amd64.whl.zip

[pthom]

I confirm that this is a serious bug in GitHub runners: see https://stackoverflow.com/questions/78829691/github-runner-produce-unreliable-executable-when-using-unique-lockstdmutex

[pthom]

I added a workaround with this commit

The wheels should be built here:

https://github.com/pthom/imgui_bundle/actions/runs/10231116332

[west-rynes]

These wheels worked perfect for me. Thank you.