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.
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?
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:
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.
