ABANDONED: FileSelectFolder: long delay before dialog appears

[tremolux66]

I've abandoned the FileSelectFolder() approach and rolled my own UDF to create a dialog containing the folder list in a ListView, which seems to work fine. It's also a better fit to our requirements: we don't really want the user wandering around in the folder-selection dialog, plus the UDF displays some associated info for each folder in a second column. Thanks again to the forum members who took a look at this.

I'm writing an installer script that needs to run as Administrator so it can, e.g., write files into protected directories. The problem is that when I call FileSelectFolder(), there is a 60-second delay before the dialog appears. If I run as an ordinary user (in the Administrators group), there's no delay, but I don't think that will work: for one thing, the installer needs to create a symbolic link, which a member of the Administrators group can't do unless the program is elevated. (This is Win 7 x64.)

(The installer will be run using an Admin account; the other user accounts are locked down and don't have access to the filesystem, the Start menu, Computer, etc. - it's a turnkey system.)

Any idea what causes the delay? And is there a way around it?

 

Edited December 15, 2016 by tremolux66
Question has become OBE.

[rootx]

have you checked the value Initial Dir ?? 

[tremolux66]

I left Initial Dir at the default value - empty string - which worked in the example code. If I understand that parameter correctly it's an initial folder selection, which we don't actually want or need b/c there is no default in this case; the dialog works as desired once it appears.

The installer script displays the dialog immediately with the default value when it's run unelevated, but has the delay with Run as administrator or #RequireAdmin.

(BTW, my AutoIt version is 3.3.14.2.)

[spudw2k]

Have you confirmed the delay is specifically when the FileSelectFolder line is executed?

If you insert a debug right before it, does it immediately show, and then subsequently the delay occurs?  Just making sure the issue is narrowed down.  What does the whole FileSelectFolder line in your script look like?

[tremolux66]

Here's a fragment of the code surrounding the FileSelectFolder() call:

If $iBtnNum = 2 Then
    ; Prompt user for the new build folder and restore it
    _LogWrite("Getting the build to be restored...")
    While 1
        ; Get the full path of the restoration-build folder
        _LogDebug("Calling FileSelectFolder w/root dir='" & $cWinInstRoot & "'")
        $sWinRestInstPath = FileSelectFolder("Select the build to restore", $cWinInstRoot)
        If @error Then
            ; User canceled the dialog
            _LogWrite("User canceled restore (folder select dialog)")
            _Exit($cExitRestoreCancel)
        EndIf

        ; If it's the directory pointed to by the active link, display an error and retry
        $sTemp = _GetReparseTarget($cWinActiveLink)     ; From ReparseUtils.au3 UDF
        If $sWinRestInstPath = $sTemp Then
            MsgBox($cMsgBoxFlags, $cWinErrTitle, "ERROR: Selected build is the active build --" & @CRLF & _
                                @TAB & "choose a different build")
            ContinueLoop
        EndIf

        _LogDebug("WinRestInstPath='" & $sWinRestInstPath & "'")
        
        ; ...
        
        ExitLoop
        
    WEnd
    
    ; ...
    
    _Exit($cExitRestoreSuccess)
        
EndIf

The message from the _LogDebug() immediately preceding the FileSelectFolder() shows up in the installer's GUI: it has an edit control that displays the messages from the _Log*() functions. When the compiled installer is running elevated, a spinning wait-cursor appears for 60 seconds, then the FSF dialog appears and execution proceeds as expected. Without elevation, the FSF dialog appears immediately, but then the script doesn't have admin privileges.

[spudw2k]

Dang, nothing obvious popping out here.  What is the value of $cWinInstRoot and how does it get set?  Sorry, grasping at straws here.

[tremolux66]

It's the path to the root of the installation folders & is a constant; it's set to something like "C:\Program Files\MyCompany". The "Win" component of the constant name indicates it's a Windows path (vs. "Cyg" for a Cygwin path).

We install the software builds under the root folder in directories with names of the form "MyProduct_yyyymmdd_n" (yyyymmdd_n translates to yyyy.[m]m.[d]d.n as a file version number in the .exe files). We generally leave all the installed versions in place, and create a symlink "MyProduct" to point to the active version (hence the reparse point check in the code). To switch versions like we're doing in the code above, we essentially delete the current symlink and create a new one that points to the desired folder. (There's a bit more to it than that, but you get the idea.) The software is designed to look for programs and reference data files under "C:\Program Files\MyCompany\MyProduct".

(And thanks to everyone who's looking at this. )