Windows Filebrowser by Getopenfilename - Fatal Error : the current working directory was changed ...

I'm going through the available methods to call a windows file browser that displays the file icons. My current attempt goes across Getopenfilename. This method works great in a build exe. Except, it crashes Unity when i run it in the editor and select a file. Which makes it very cumbersome to develop since i cannot see the variables changing. And building a exe after every step is a bit cumbersome.

Has somebody an idea what i could do that Unity doesn't crash?

Attached an example file. It contains a JS version of the script. And a C# version of the script. So language shouldn't be the issue here.

 

So, if it works in stanalone app, but does not work in Editor, mabe problem in file path? I don't like this line:

Code (csharp):

1. saveCurrentDirectory = Environment.CurrentDirectory;

Maybe using of EditorApplication.applicationPath will be better then Environment.CurrentDirectory? See an exapmle in the Scripting References.

 

Thanks Pati Co. It was a nice idea. But nope, same crash again.

 

Just notice. Editor crashed at line 26, there is calling DllImport method. So, I think this is a root cuase, it can be impossible to call Comdlg32.dll from Editor. Do you tried to google it?

 

Thanks for the hinkt Pati Co. That would be bad. I still hope for a solution

I have of course tried my google fu. But without any bigger luck so far.

 

I have the same problem. I am not sure why Unity thinks (or does) change its working directory when I call Getopenfilename.. ! Anyone?

 

Well I'm not sure why Unity needs the Current Working Directory to be the Project folder (or why this would cause it to crash). But your program (not Unity) is changing its Current Working Directory when you use the GetOpenFIleName. This brings up a window for the user to type in a file name, and browse your computer like Explorer does. (the OS File browser, not the Web Browser).

So whats hapenning is you call the GetOpenFIleName which changes the CWD to whatever its default is, then sits there waiting for User Events (Button Presses and KeyStrokes). Meanwhile directly after you call that filename your code continues on, and eventually returns control back to unity which FREAKS out because the CWD isn't the project folder anymore.

Unfortunately I suspect the GetOpenFileName Dialog uses constant calls to change the directory as the user browses. The only fix for this would be to rewrite your own GetOpenFileName that stores a path variable that is the Dialogs's working directly.. Then it displays all the things it should based on that directory. but then immediately sets the CWD Back to the project folder. Everytime it processes a ButtonPress or whatever to change folders, it can call change directory function, get the info it needs and display stuff.. then reset back to Project folder directory(saving its current directory in its variable).

The GetOpenFileName has been deprecated and replaced by this:
https://msdn.microsoft.com/en-us/library/windows/desktop/bb776913(v=vs.85).aspx

You could try opening that instead and see if it is safer about keeping the current working directory where you have it.

Googling about OpenFIleDialog changing current working directory shows that it is indeed only for that older deprecated Control . The newer one for windows7 and vista does not change your current working directory. It does what I described above.

 

Maybe you didn't set Flsgs's OFN_NOCHANGEDIR value to 0x00000008.(OFN_NOCHANGEDIR 0x00000008

 

delete this ofn.initialDir = Application.dataPath.Replace('/', '\\') + '\0';do not change initialDir;Otherwise unity will crash