Don't use nullptr in fileOpenDialog->Show about nativefiledialog-extended HOT 3 OPEN

Yeah, I think this is an issue on both Windows and Linux. I didn't implement this because all the known solutions to determine the parent window are guesswork if NFD isn't given a handle to the main window (e.g. the find_main_window solution you've linked), but yet it would be quite simple for the caller to get the correct window handle and tell NFD about it (assuming the proper API is added to NFD).

The main concern with having the window handle passed explicitly is that it is platform-specific, which means that we need separate platform-specific APIs on each platform NFD supports. But even though it's a bit difficult to use, I think this is the more proper solution and should be preferred to the guesswork you're proposing. Since most users of NFD use a windowing library like SDL2 or GLFW, we could potentially add a way to accept a SDL2 or GLFW window handle (in a separate header, so the NFD library itself doesn't need to depend on those things) and get the platform-specific native handle from it.

from nativefiledialog-extended.

Yes, I understand that passing the handle to the window would break compatibility.
That is why I have made this proposal that in the worst case (the window handle is not found and find_main_window returns nullptr), it would be the current situation.

from nativefiledialog-extended.

Sorry, I think I wasn't very clear.

I don't think the logic of find_main_window should be part of NFD, since it is guesswork, and for multi-window applications it might bring the wrong window to the top. Instead, I think NFD ought to have a new interface that will allow the user to pass in a native window handle, and the user should implement their own find_main_window hack if they want to do so (or better, figure out the correct window handle through a more proper way and pass that to NFD).

This should be implementable after #92 is implemented.

from nativefiledialog-extended.