_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.
• 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_5_0.pdf
Comments and suggestions are most welcome.
I have a question please
Is there a way to request the script for administrator privileges if a particular condition is met??
local $path = RegRead("HKEY_CURRENT_USER\Software\test", "fullpath")
if $fullPath = @scriptFullPath then
Request for administrator privileges
I hope to find a solution here
Greetings to all
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] 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? ^^
Morning! I've searched for a definitive answer on the forums on this but can't find one so here goes. I need admin for one of my functions so I'm using #RequireAdmin. I then noticed that regardless of that function being used or admin actually being required, the program pops up and requires admin all of the time.
Is this the way it's designed and is there a way around it so that I can launch my program as normal until admin is required, then and only then prompt the user to run the program as admin?
The only solution I could think of is to produce 2 executables and do something like:
$adminrequired = 1 If($adminrequired = 1) Then Run(Run first executable which includes #RequireAdmin) Else Run(Run second identical executable without #RequireAdmin) EndIf Obviously I'd rather keep to making a single executable rather than having 2 or 3!
After a few weeks of researching and testing, I think I have a good understanding of #RequireAdmin and IsAdmin() for an individual script. They both work in conjunction with each other and ignore whether the current user has administrator rights, or not. In other words, IsAdmin() doesn't test the user, only the declared permission level of the script it is executed in. A separate check is needed to actually confirm the user's admin level. I've included a test script that demonstrates the difference.
Here is my question: When a compiled scripts runs with administrative rights, does a script that it runs inherit those rights? Or is every script on its own? For example,
Parent Script ... (doesn't need admin rights) ... that runs:
Child Script ... that does need admin rights, and obtains them via #RequireAdmin + user's response ... and then runs:
2nd Child Script ...<< does this script execute with admin rights, or not?
If a script does not automatically inherit rights, then is there a way for a parent script that has admin rights to run a child script "with rights", so that running the child script does not result in another prompt for user permission?
Thanks in advance for any help.
;#RequireAdmin ; enable or disable this line to see the difference $AdCheck = IsAdmin() MsgBox(0, "Admin Test", "Admin is " & $AdCheck) $AdCheck = _IsAdministrator() MsgBox(0, "Admin Test", "Admin is " & $AdCheck) Exit Func _IsAdministrator($sUser = @UserName, $sCompName = ".") Local $aCall = DllCall("netapi32.dll", "long", "NetUserGetInfo", "wstr", $sCompName, "wstr", $sUser, "dword", 1, "ptr*", 0) If @error Or $aCall Then Return SetError(1, 0, False) Local $fPrivAdmin = DllStructGetData(DllStructCreate("ptr;ptr;dword;dword;ptr;ptr;dword;ptr", $aCall), 4) = 2 DllCall("netapi32.dll", "long", "NetApiBufferFree", "ptr", $aCall) Return $fPrivAdmin EndFunc