FileOpenDialog

[Dana]

I don't know if this is an issue with the FileOpenDialog function itself, windows 10, or the helpfile, but:

The second parameter for FileOpenDialog is "init dir".  If that directory exists, no problem.  If that directory doesn't exist, it seems to default to the script directory... at least the first time.  If you browse to a different folder, the next time you use the function, the dialog opens in the last directory you used.  Even if you exit the program (or SciTE if you're running it from there) and rerun the program, it still goes back to that same directory last used.  Is this intended behavior, or something windows 10 is doing?  Where is that last directory stored?  I couldn't find it in the registry.  Interestingly, if the "init dir" directory is then created, the file open dialog will then properly open in that location.

To summarize, it looks like FileOpenDialog uses the "init dir" if it exists, the last directory used if "init dir" doesn't exist, and the script directory if there is no last directory used.  If that's expected behavior, should it not be in the help file?

ConsoleWrite("working directory:  " & @WorkingDir & @CRLF)
ConsoleWrite("script directory:  " & @ScriptDir & @CRLF)
While 1
    $FilePath = FileOpenDialog("Select Input FIle", @ScriptDir & "\data", "All (*.*)")
    If @error Then Exit
    ConsoleWrite("Selected file:  " & $FilePath & @CRLF)
    ConsoleWrite("working directory:  " & @WorkingDir & @CRLF)
WEnd

 

[Jfish]

The help file says:

Quote

@WorkingDir is changed on successful return.

I am guessing that is what you are seeing ... ?

Edited August 28, 2019 by Jfish

[Dana]

It is indeed using the same directory as @workingdir (which starts out the same as @scriptdir until something changes @workingdir).  But when the program (or SciTe) completely exits and I run the script again, @workingdir is again the same as @scriptdir... but it's still looking for the file in the directory used last time the program was run, not the current @workingdir which was reinitialized to @scriptdir when the program restarted.

 

[KaFu]

I think it defaults to somewhere here if the folder does not exist:

\HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\ComDlg32\

Couldn't find a quick way to decoded those MRUs properly though.

I use a custom version of _FileOpenDialog_Ex() to reset @workingdir to the initial script workingdir (because the new workingdir is blocked from deletion).

Add a test to initdir there and you're golden.

Func _FileOpenDialog_Ex($sTitle, $sInitDir, $sFilter, $iOptions = 0, $sDefaultName = "", $hWnd = 0)
    #cs
        https://groups.google.com/forum/?hl=en&fromgroups=#!topic/microsoft.public.vc.mfc/HafQr4gIRY0
        The problem is that GetOpenFileName changes the current directory to the
        last browsed one. The current directory and any of its parents cannot be
        deleted.
    #ce
    Local $sWorkingDir = @WorkingDir
    if not StringInStr(FileGetAttrib($sInitDir),"D") then $sInitDir = @ScriptDir
    Local $sFilename = FileOpenDialog($sTitle, $sInitDir, $sFilter, $iOptions, $sDefaultName, $hWnd)
    Local $iError = @error
    FileChangeDir($sWorkingDir)
    Return SetError($iError, 0, $sFilename)
EndFunc   ;==>_FileOpenDialog_Ex

 

Edited August 29, 2019 by KaFu

[Dana]

Thanks... it's not actually a problem, I was just trying to understand what's happening.  I'm guessing that Windows takes over if the init dir isn't valid, using the MRU directory if available, and the program or script directory if it isn't, and that Autoit isn't involved in that decision at all if the init dir doesn't exist.