Jump to content

ABANDONED: FileSelectFolder: long delay before dialog appears


Recommended Posts

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 by tremolux66
Question has become OBE.

When the going gets tough, the tough start coding.

Link to post
Share on other sites

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.)

When the going gets tough, the tough start coding.

Link to post
Share on other sites

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?

Link to post
Share on other sites

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.

When the going gets tough, the tough start coding.

Link to post
Share on other sites

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

Link to post
Share on other sites

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

When the going gets tough, the tough start coding.

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    No registered users viewing this page.

  • Similar Content

    • By rudi
      Hi,
      When a non compiled AU3 script is run with #RequireAdmin, then if the UAC prompt can be authorized due to the fact, that the currently loggedon user has local admin rights, then the macro @UserProfileDir correctly reflects the profile dir of the user of the windows logon session.
       
      When the script with #RequireAdmin is started by a "normal user" without local admin rights, and I use a domain admin account to authorize the UAC prompt, then @UserProfileDir reflects the profile dir belonging to the AD-Admin account.
      As the script originally was started using the "regular user" I'm wondering, if there is a chance to "pass" the original user's @UserProfileDir to the UAC elevated script?
       
      As playing around with this feature I realize, that I basically don't know the exact mechanism of the UAC elevation authorization process:
      The script is started by right mouse click, execute script This is invoking e.g. "C:\Program Files (x86)\AutoIt3\AutoIt3.exe" "C:\Users\Rudi\Desktop\test.au3" as by this registy value: Windows Registry Editor Version 5.00 [HKEY_CLASSES_ROOT\AutoIt3Script\Shell\Run\Command] @="\"C:\\Program Files (x86)\\AutoIt3\\AutoIt3.exe\" \"%1\" %*" But what I honestly don't know is, how does the UAC propt interact in the program startup? I guess, that Autoit3.exe is parsing the AU3 source, is seeing the #RequireAdmin and then "relaunches itself with the AU3 as %1" requesting UAC elevated rights "from windows"??? With Process Explorer I can see, that The commandline then is this one with a "!" before "%1"
      "C:\Program Files (x86)\AutoIt3\AutoIt3.exe" !"C:\Users\Rudi\Desktop\test.au3"  It it should be something like this, then it might be possible to pass the original @UserProfileDir to the second, UAC elevated "Startup"??? <edit>
      I just noticed:
      When I use "WIN+R" and then directly use the command line, I see in Process Explorer, ...
      "C:\Program Files (x86)\AutoIt3\AutoIt3.exe" !"C:\Users\Rudi\Desktop\test.au3"
      ... then this script with #RequireAdmin is started *WITHOUT* UAC elevation.
      Guessing, that this ! is just reverting #RequireAdmin I tried the "opposite" one as well:
      AU3 script without #RequireAdmin Starting with "C:\Program Files (x86)\AutoIt3\AutoIt3.exe" !"C:\Users\Rudi\Desktop\test.au3" does not invoke UAC elevation prompt. So to me it looks like, this ! is a "status flag from Autoit3.exe to Autoit3.exe", that the elevation process was done already? amazing...
      the topic Autoit on Windows Vista is telling no details of  this UAC process...
      </edit>
       
      Regards, Rudi.
    • By c.haslam
      _
      _cFileSelectFolder() is intended as a replacement for native FileSelectFolder() for selecting folders: It implements the left pane of FileSelectFolder(), and goes beyond FileSelectFolder() in several ways.
      Features:
      •    It is user friendly and designed to be easy to use;
      •    New folder, Delete folder and Rename folder controls are optional;
      •    Its GUI can be placed anywhere, including centred on another window;
      •    Neither needs nor uses CLSIDs;
      •    Checks calling parameters rigorously, with the user choosing either to show error messages in a dialog or to set @error and return them to the caller;
      •    For local and mapped drives, accepts file specifications with drives that can be drive letters, drive labels, or both,
      •    For local and mapped drives, always returns drive letter:\ ...\ so its output is compatible with native AutoIt functions.
      •    For UNC paths, returns \\computer\share\...\
      •    For unmapped drives on computers on the network,  offers a shortcut to shares.
      •    Selecting a treeview item to be highlighted initially is specified in a user-friendly way, including a diagnostic for when the user gets it wrong
      •    Because it can be called with many arguments, a user can show a list of the arguments / parameters and their values
      The root of the treeview can be:
      •    The Desktop hierarchy with Desktop at the top
      •     Partial Desktop hierarchy with any other Desktop item at the top, with or without local/mapped drives and file folders, or remote shares and file folders (as appropriate),
      •     Local/mapped drives and file folders, or
      •    Remote shares and folders.
      The script and example scripts are in the zip file. Documentation beyond what is in the UDF header is  in the PDF file,   cFileSelectFolder 1_6_1.pdf
      Comments and suggestions are most welcome.
       
       
       
      cFileSelectFolder 1_6_1.pdf
    • By YawStar
      Hi there. I want to add my FileSelectFolder function with "include subdirectories Checkbox". The example image is shown in below.

    • By nacerbaaziz
      Hello all
      I have a question please
      Is there a way to request the script for administrator privileges if a particular condition is met??
      example
      local $path = RegRead("HKEY_CURRENT_USER\Software\test", "fullpath")
      if $fullPath = @scriptFullPath then
      Request for administrator privileges
      main()
      else
      main()
      endIf
      I hope to find a solution here
      Greetings to all
    • By Gringo
      Hi,
      I'm trying to:
      -Select a file in a folder (to store it to an ini file)
      -Write the file on an ini
      -Copy files to the folder selected by the user
      instead of using FileOpenDialog then FileSelectFolder, I was wondering if it was possible to do the whole thing only with FileOpenDialog spliting the value returned in 2 variables. I got something like that for the first part (select a file and store it to an ini file)
      Local $message = "Select your executable" Local $pathk = FileOpenDialog($message, "C:" & "", "Select the executable you want to terminate (*.exe)", 1 + 4) Local $path = "None" ;ici je dois copier les fichiers $split = StringSplit($pathk, "\") $tokill = $split[$split[0]] If @error Then MsgBox(4096, "", "No Executable chosen") Else MsgBox(4096, "", $pathk & " Will be terminated " & @LF & @LF & "Press OK to EXIT ") IniWrite(@ScriptDir & "\path.ini", "Torun", "path", $path) IniWrite(@ScriptDir & "\path.ini", "Tokill", "pathk", $tokill) EndIf As you can see I manage to split the value returned by FileOpenDialog to have only the exe but as a noob I can't manage to get the path to copy the files I need to the same path.
      Any idea? ^^
×
×
  • Create New...