UnityStandaloneFileBrowser
UnityStandaloneFileBrowser copied to clipboard
gkngkc
Crash when saving over existing file in x86 Windows builds (crashes before asking to replace)
Steps:
- Create an x86 Windows build containing the BasicSampleScene in this repo.
- Run the application and press "Save File" on the left buttons.
- Choose an existing file (intention to overwrite).
- Save.
- Instead of the dialog asking to replace the file, the build will crash.
On x64 builds this does not happen (nor in the editor, which is also 64 bits). Any ideas of why this might be? Maybe this is a known problem.
We are testing this in Unity 2018.4.5f1, although this also happens on a production build made with 2017.4.11f1 (where we found the problem). We are using Mono (the build process crashes when using IL2CPP and we don't need it right now) and .NET 4.x Equivalent as the scripting runtime.
Best regards, Daniel Lobo
I assume that, if confirmed, this would actually be an error in the dll for Windows.Forms...? (that is what UnityStandaloneFileBrowser uses, right?) Or some incompatibility between it and my system/Unity settings.
This seems like a similar problem, though the "solution" was to disable the overwrite prompt for the case that crashes. :(
Hi! Got exactly the same error reported by users from my app on Steam. @gkngkc help us please!
Hey @hippogamesunity, I don't think gkngkc is maintaining this anymore.
In my team, we managed to solve the bug by replacing a DLL after some trial and error. It was not me who made the fix but, if I'm not mistaken, my colleague replaced StandaloneFileBrowser/Plugins/Ookii.Dialogs.dll with a newer Ookii.Dialogs.dll file from some repository fork of Ookii Dialogs. It fixed the problem without any secondary effects that we could find.
I can find out what it was exactly and let you know tomorrow or at least in the next few days.
In the meantime maybe try using the dll in this zip from the main Ookii Dialogs page: http://www.ookii.org/Download/Dialogs
Maybe it was this one, I'm not sure until I can take a look at our commits at work.
@CanisLupus Thanks, it works with this new DLL on x86! I can also confirm that switching to x86_64 can fix the issue on x64 machines. Good luck!
You're welcome, happy to hear it! :) Today I checked our DLL and it turns out that we compiled it from this GitHub repo, so it's definitely not the one from the archive above. However, since you say that that one also works, I guess that's the one to use. :)