benched42

I use ISN AutoIt Studio and have never used any version of SciTE (I used PSPad before I used AutoIt Studio) and I have no issues using the AutoIt3Wrapper directives.

Is there a way to differentiate between a left click and a right click on a tray icon? I have an application that I want to show the main window when the primary mouse button is clicked but when the secondary mouse button is clicked I want a menu with items like About, Settings and Exit in it. The entire script I'm working on is over 1100 lines long, so I'd rather not post it all but I can if people think it would be helpful.

I have found there's a difference between Windows 7 and Windows 10. For both Windows 7 and Windows 10, the AutoIt macro @DesktopCommonDir returns "C:\Users\Public\Desktop. That is actually the Windows 7 Public user's desktop. However, in Windows 10, the Public user's desktop is "C:\Users\Public\Public Desktop". I've had to modify some of my scripts to take this into account. This is what I have found in my scripts here at work. Not sure if Home versions of Windows 10 or Windows 7 are different.

To get the actual color, it's not stored as 0xFFrrggbb, where rr=red byte value, gg=green byte value, bb=blue byte value. I wrestled with this same issue and found that Microsoft, for some reason, stores the color as 0xFFbbggrr , the exact opposite order of an RGB value. Here are the three lines I used to get the RGB value: $theMWTitleBarColor = Hex(RegRead("HKEY_CURRENT_USER\Software\Microsoft\Windows\DWM", "AccentColor")) $theMWTitleBarColor = StringRight($theMWTitleBarColor, 6) $theMWTitleBarColor = "0x" & StringRight($theMWTitleBarColor, 2) & StringMid($theMWTitleBarColor, 3, 2) & StringLeft($theMWTitleBarColor, 2) I used it in my own function to generate a message window with a fake title bar (so the window can't be dragged anywhere). I also used a different registry key, but when I compared the values on my system they were the same so you can continue to use the registry key you have been using.

One other thing to consider: Does the local administrator account have network access? I know that on our network where I work, I can only run local files as a local admin.

The file "Offline.ico" needs to be in the same folder as your script, whether the script is compiled or not. Looking at the code you have it seems that when compiling it can add the "Offline.ico" to be the icon used by the EXE file. But that does nothing for the button. Typically, here's what I do: 1. I use a function to create a random folder within the user's temp folder: ; #FUNCTION# ==================================================================================================================== ; Name ..........: __RandomTempFolder ; Description ...: Creates a random temp folder to use while this is running in order to store any files needed and included in ; the script run ; Syntax ........: __RandomTempFolder() ; Parameters ....: None ; Return values .: None ; =============================================================================================================================== Func __RandomTempFolder() Local $theFolderName, $i, $theRandomCharacter $theFolderName = "\~" For $i = 1 To 10 $theRandomCharacter = Random(97, 122, 1) $theFolderName = $theFolderName & Chr($theRandomCharacter) Next Return $theFolderName EndFunc ;==>__RandomTempFolder 2. I use a variable within the script and set it to the path of the newly created temp folder: $theSource = @TempDir & __RandomTempFolder() 3. I then use an initializing function to place all of my needed images in the newly created folder (this only shows .ICO icon files, but they can be any file type that your script might need): ; #FUNCTION# ==================================================================================================================== ; Name ..........: __Initialize ; Description ...: Makes sure that images and support files exist for this wizard ; Syntax ........: __Initialize() ; Parameters ....: None ; Return values .: None ; =============================================================================================================================== Func __Initialize() If FileExists($theSource) Then DirRemove($theSource) EndIf DirCreate($theSource) FileInstall("{the exact path to the image file}\error.ico", $theSource & "\error.ico", 1) FileInstall("{the exact path to the image file}\info.ico", $theSource & "\info.ico", 1) FileInstall("{the exact path to the image file}\question.ico", $theSource & "\question.ico", 1) FileInstall("{the exact path to the image file}\warning.ico", $theSource & "\warning.ico", 1) EndFunc 4. Finally, when I set the button with an image on it, I use the path to the image file (I typically use variables to place the buttons and set the size of the buttons so that if I need to make the overall window wider or taller, the buttons adjust accordingly): $btnMsgOK = GUICtrlCreateButton("", {button left}, {button top}, {button width}, {button height}, $BS_ICON) GUICtrlSetImage(-1, $theSource & "\ok.ico") GUICtrlSetTip(-1, "OK", "", 0, 1) One more thing: I always, always, always delete the random temp folder after closing the window at the end of a script run. Windows doesn't clean up after itself, but that doesn't mean my scripts shouldn't.

Well I tried that at one time by building the admin password one character at a time using the CHR() function. For a password of "Password1" the code I wrote initially was very rudimentary: $theAdminPassword = Chr(80) & Chr(97) & Chr(115) & Chr(115) & Chr(119) & Chr(111) & Chr(114) & Chr(100) & Chr(49) Doesn't do a lot to stop a clever and determined user, but does obfuscate it somewhat. Another way is to put the numbers into a text file and read them line by line to build the admin password. Then you can easily change admin passwords without rewriting code. I wrote something like this later as we changed our admin password: $fHandle = FileOpen({some UNC path to a public file on the network}, 0) $theAdminPassword = "" While 1 FileReadLine($fHandle, $theChar) If @error ExitLoop Endif $theAdminPassword = $theAdminPassword & Chr($theChar) WEnd FileClose($fHandle)

You can do that if you know the Administrator or System password. However, even if you obfuscate the password it could be obtained by a clever user.

Thank you so much! I compared the @LogonDomain with @ComputerName to determine if the computer was connected to the domain or not; I think it runs much faster now!

I've been using your Active Directory UDF for several years now in a script I have written to automatically gather information on a computer's user and the computer hardware and software for use when calling our helpdesk. The information it gathers is very complete. I just have one question that has recently been asked by my manager: When the script is run when the computer is not connected to our domain, it takes at least 20 seconds to determine that it is not connected before continuing. All data gathered from Active Directory is set to "Not connected to domain" when the computer is not connected. However, when run a second time when not connected to the domain, it seems to take only a second or two. In addition to this, when the user connects to our domain using VPN, it takes only a second or two to gather the Active Directory data; however, when run after disconnecting from VPN it repeats the same behavior demonstrated before connecting to VPN: first run about 20 seconds, subsequent runs only a second or two. Is there some kind of information left by the AD UDF that it is accessing after that? Or is that typical behavior for Windows? The script is being tested on a Lenovo Yoga X380 with Windows 10.

Not sure, but isn't a plus sign (+) an illegal character for a file path to contain? Going back to the old DOS days, it was because copying could contain a plus sign among its parameters.

Without designating an initial path (by leaving it the null value) for FileSelectFolder, my guess is that it would open in the default opening folder for Windows Explorer. You can set that, or you can manually set it to be whatever folder you'd like in the second parameter.

Another option is to use Melba23's excellent UDF ExtMsgBox.

" Unfortunately it does not work for other PCs. " Are these other PCs on a domain? If so, are they Windows 10? And if so, do the individual users have admin rights? Where I work, admin rights are restricted to a very few which renders a lot of scripts I wrote in the past unusable. One example of such a script would be to add a local printer - one needs admin rights to do that. In the case of your autostart issues, one needs admin rights to write to @StartupCommonDir, but admin rights are not needed to write to @StartupDir. In addition, admin rights are required to add or change data in the "C:\Program Files", "C:\Program Files (x86)" and "C:\Program Data" folders.

At home, I have UAC turned off on my workstation, but I have the default setting for her laptop (I didn't change it and she doesn't know how). When I was removing software from her laptop this past weekend, I got the UAC prompt on her system. You get the prompt because changes are being made to the computer, to the point, more than one user's profile on the computer. At work we have our computers locked down to the point that a user can't install new software (outside of our Software Center from SCCM) or hardware without contacting our Service Desk for a one-time keycode to use to install said hardware and software. That's why I choose to install any of my scripts in the user's profile - no UAC prompt.