
Gigglestick
Active Members-
Posts
489 -
Joined
-
Last visited
Gigglestick's Achievements

Universalist (7/7)
2
Reputation
-
algiuxas reacted to a post in a topic: Animated Gif using GDI+
-
stealthmsgr reacted to a post in a topic: _FileInPath( filename ) UDF
-
I logged into my work machine today to find that McAfee Enterprise 8.8 had deleted all my compiled scripts. They were detected as: PWSZbot-FCI!AC1937DAED4 PWSZbot-FCI!894E56FD5AAF I just thought I'd mention it in case someone wants to follow up with McAfee.
-
@MHz - Thanks for testing those scenarios. I clearly hadn't checked all the logic. I think it'll work much better now. The original post has been updated. @JohnOne Maybe this will help: Script: C:\Myfiles\Scripts\MyScript.exe File: C:\Myfiles\Scripts\Data.txt PATH: c:\windows\system32;c:\windows @WorkingDir when the script starts is C:\Myfiles\Scripts, so if we _FileInPath("Data.txt") it'll check C:\Myfiles\Scripts and find the file. If you FileChangeDir("C:\") then _FileInPath("Data.txt") again, it'll check C:\ (@WorkingDir, not found), c:\windows\system32 (not found), and c:\windows (not found). So even though the file is in @ScriptDir, we're only looking in the "current" folder and the PATH. This is how other things in Windows work. If you hit Start and Run, and type "cmd" it's looking in the working directory, which is your HOMEPATH (another environment variable), then it'll check each directory listed in the PATH. Unless you have changed it, C:\Windows\System32 is in the PATH by default, so it finds cmd.exe there and runs it. When it starts cmd.exe, it starts it in your HOMEPATH instead of the System32 directory because it's more likely that things relevant to you will be on your home drive than under the System32 directory. From cmd.exe's perspective its own @ScripDir is C:\Windows\System32, but its @WorkingDir is your HOMEPATH.
-
You were trying to recreate the $CmdLine funcionality to process the $CmdLineRaw passed to another instance of the script. Yep. Got it. Nicely done.
-
I'm just saying your _CmdLineRaw() function still spits out an array, which is not what you seem to need for WM_COPYDATA. You've recreated the built-in $CmdLine functionality. You still have to loop through an array to create whatever you need to pass to WM_COPYDATA, whether it's using the built in $CmdLine or your own array... unless I've completely missed the point, which is not altogether impossible. Don't get me wrong, it's a nice function, and I may someday find a use for it in my own scripts, but I don't think it accomplishes what you're asking in relation to WM_COPYDATA.
-
I get that you can't pass an array using WM_COPYDATA, but you've created a function that turns a command-line formatted string into an array. Basically, you've made a function that does the same as the built in $CmdLine, but allows the input to be something other than the actual command line given to the script. That's great if you plan on creating your own list of files in the same format as a command line and then converting it to an array, but doesn't help you at all in the goal of passing a bar ("|") delimited string to WM_COPYDATA. You'll still have to convert the output of your function to a string.
-
How about instead of limiting the location of robocopy.exe? $roboCopyCMD = _FileInPath("robocopy.exe") If $roboCopyCMD = "" Then Return SetError(1, 0, "")Also, it's SetError(@error, @extended, return value). You used SetError(0, "", 0).
-
I did a quick search for it on the forums, but maybe I missed it, so I made my own. It searches the PATH environment variable Example: ConsoleWrite(_FileInPath("robocopy.exe") & @CRLF)UDF: ; #FUNCTION# ==================================================================================================================== ; Name...........: _FileInPath ; Description ...: Returns the location in the PATH environment variable containing a file ; Syntax.........: _FileInPath( $sFilename ) ; Parameters ....: $sFilename - The file to search for (filename only, no folders) ; Return values .: Success - Returns the path to the file and set @error=0 (@extended=1 a specified path and the file is there) ; Failure - Returns "" and sets @error: ; |1 - File not found in @WorkingDir or the PATH (@extended=1 if PATH is blank) ; |2 - Could not StringSplit the PATH ; Author ........: Gigglestick (c0deWorm) ; Modified.......: Comments added and logic modified ; Remarks .......: ; Related .......: ; Link ..........: ; Example .......: ; =============================================================================================================================== Func _FileInPath($asFilename) If StringInStr($asFilename, "\") Then If FileExists($asFilename) Then ; if a full or relative path was specified and the file exists then return the path Return SetError(0, 1, $asFilename) Else ; if a path was specified and the file does not exist then return "file not found" error Return SetError(1, 0, "") EndIf EndIf ; if the file is found in the current working directory then return the absolute file path If FileExists(@WorkingDir & "\" & $asFilename) Then Return SetError(0, 0, @WorkingDir & "\" & $asFilename) Local $i, $lasPath, $lsPath = EnvGet("PATH") ; if variable containing PATH is empty then return "file not found" error and @extended=2 If StringLen($lsPath) = 0 Then Return SetError(1, 1, "") ; if PATH is set but only has one entry then check it If StringLen($lsPath) > 0 And Not StringInStr($lsPath, ";") Then If FileExists($lsPath & "\" & $asFilename) Then ; if the filename is found in the single PATH entry then return the file path Return SetError(0, 0, $lsPath & "\" & $asFilename) Else ; if PATH is a single entry and does not contain the filename then return "file not found" error Return SetError(1, 0, "") EndIf EndIf ; remove any blank entries (double semicolons) While StringInStr($lsPath, ";;") $lsPath = StringReplace($lsPath, ";;", ";") WEnd ; split variable containing PATH into an array of single paths $lasPath = StringSplit($lsPath, ";") ; if ";" not found in split then return error If @error Then Return SetError(2, 0, "") ; loop through array of single paths, searching for absolute file path and return absolute file path if found For $i = 1 To $lasPath[0] If FileExists($lasPath[$i] & "\" & $asFilename) Then Return SetError(0, 0, $lasPath[$i] & "\" & $asFilename) Next ; unable to find filename in current working directory or PATH so return error Return SetError(1, 0, "") EndFunc ;==>_FileInPathEdit - May 10: Evaluated MHz's comments and revised the code. It should work much better now. If a full or relative path is specified and the file exists there then return that path, or @error=1 (file not found)If the file exists in the @WorkingDir then return that pathIf the PATH is empty then return @error=1 and @extended=1If the PATH contains only a single entry, and it contains the file then return that path, or @error=1 (file not found)Clear blank entries (consecutive semicolons) from the PATHSplit the path and check each entry for the file, returning the path if foundIf none of the above works then @error=1 (file not found)
-
Ultimate Talker (pretty sick multi-chat) version 23!
Gigglestick replied to ludocus's topic in AutoIt Example Scripts
Not to be an ass, but if the only thing holding you back from releasing the source is that it has passwords in it, how time consuming could it possibly be to remove passwords (hint: blank the variables and zip'er up)? -
When running that last example (compiled and dropping a couple dozen files/folders on it), and adding an _ArrayDisplay($CmdLine) after yours, the only difference I see is that yours is a zero-based array and the built in $CmdLine is 1-based with a count.
-
Very nice work, and I like the combination with InlineMe. It occurred to me that it might be possible to use an include file with an external compiled script to compile your script as 64-bit, then embed that into the script and recompile as 32-bit. Then check which platform the script is running on and run the 64-bit version from memory. Theoretically, all you would have to do is set a Run_Before directive in your script and all the magic would happen automatically. @trancexx mentioned it'd be necessary to change the structures when embedding a 64-bit program inside a 32-bit one, so that'd have to be done for this. Here's an early draft. In your script: #Region ;**** Directives created by AutoIt3Wrapper_GUI **** #AutoIt3Wrapper_Run_Before=Compile64bit.exe /before "%in%" #EndRegion ;**** Directives created by AutoIt3Wrapper_GUI ****Compile64bit.exe /before "%in%": Modify your script:...Disable #AutoIt3Wrapper_Run_Before=Compile64bit.exe /before "%in%"...Add #AutoIt3Wrapper_UseX64=yCompile your script as X64Modify your script:...Add #AutoIt3Wrapper_Run_After=Compile64bit.exe /after "%in%"...Remove #AutoIt3Wrapper_UseX64=y...Use InlineMe functions to convert the compiled script into a variable...Add the region belowExit and let your script compile normallyCompile64bit.exe /after "%in%": Modify your script:...Enable #AutoIt3Wrapper_Run_Before=Compile64bit.exe /before "%in%"...Remove #AutoIt3Wrapper_Run_After=Compile64bit.exe /after "%in%"Region added by Compile64bit.exe /before "%in%": #region ;**** Compile64bit **** #include <RunBinary.au3> $__sCompile64bitData = "" ; Compile64bit.exe uses InlineMe functions to generate the binary data If @AutoItX64 Then Exit _RunWaitBinary($__sCompile64bitData, $CmdLineRaw) ; Version of RunBinary that waits for the embedded program to finish, then issues the exit code generated by it EndIf #endregion ;**** Compile64bit ****Edit: Changed it from trying to do it all with an include file to just adding #AutoIt3Wrapper_Run_Before to your script and having Compile64bit.exe do all the work.
-
Dynamic Menu creation using ini file
Gigglestick replied to Mjolnir's topic in AutoIt Example Scripts
Simpler: $Ini_File = StringTrimRight(@ScriptFullPath, 4) & ".ini" -
Control Viewer - AutoIt Window Info Tool
Gigglestick replied to Yashied's topic in AutoIt Example Scripts
Wow, extremely impressive. This should definitely replace the one packaged with AutoIt3 whenever the next version is released. -
Nice work. Personally, I like to use adlibs instead of timers when feasible. Opt("MustDeclareVars", 1) Global $gsDataDir = @WorkingDir & "/Data" If Not FileExists($gsDataDir) Then DirCreate($gsDataDir) AdlibRegister("_AdlibLogStats", 60000) ; 60 seconds AdlibRegister("_Exit", 86400000) ; 24 hours (1440 min, 86400 seconds, 86400000 milliseconds) While 1 Sleep(1000) WEnd Func _AdlibLogStats() Local $i, $lsNow = @YEAR & "/" & @MON & "/" & @MDAY & " " & @HOUR & ":" & @MIN & ":" & @SEC Local $laProcessList = ProcessList() If @error or Not IsArray($laProcessList) Then Return SetError(1, 0, False) For $i = 1 to $laProcessList[0][0] FileWriteLine($gsDataDir & "\" & $laProcessList[$i][0] & ".log", $laProcessList[$i][1] & "<>" & $laProcessList[$i][1] & "<>" & $lsNow) Next EndFunc Func _Exit() Exit 0 EndFunc I haven't tried it out yet, but I kind of like the idea. An INI file or a GUI would be nice to define how often to log processes, how long to log before stopping. Anyway, I get that the process monitor script was a quick and dirty version just to get something usable to graph. The graphing is the real work here. One thought on the graphing. I see you have functions for fixed time functions. Why not have a single function to which you pass a variable timeframe entered via an edit control or a slider control or something?
-
Oh, and it might be good to have functions for access to the current username and access level. The global variable is usable too, but IMO it's better to "hide" those and use functions to get their values. ; "Default" in any of the "New" parameters would keep the current value If _UserLogin() Then ; True if the user has been logged in If _UserLogout() Then ; True if the user has been logged out If _UserLoginAdmin() Then ; True if the user has been logged in as an admin If _UserIsAdmin() Then ; True if the user is an admin If _UserCreate(Username, Password, Access Level) Then ; True if the user was successfully created (the INI save was successful) If _UserEdit(Username, New Username, New Password, New Access Level) Then ; True if the edit was successful If _UserDelete(Username) Then ; True if the user was deleted Last, you might check out the format of some of the UDF include files packaged with AutoIt3 for formatting. Specifically, attempting to make global variables and internal functions (ones you don't intend users to use directly) unique by using multiple underscores (e.g. $__sUsername or Func __CreateNewUser). Good luck. Looking forward to the end product.
-
Nice start; it has potential. Check out _Crypt_HashData to help make it secure. You could store the password in its hashed form, then hash the password field on your GUI and compare that to the one stored in the file. If they match, the password is good. If _Crypt_HashData( [ PASSWORD FROM THE GUI ], $CALG_MD5) = [PASSWORD FROM THE INI FILE] Then MsgBox(64,"Access Granted","Password correct!") Else MsgBox(16,"Access Denied","You entered the wrong password!") EndIf Another option might be to combine the username, password and level of access into the string you run through the hash, so that you could store a single entry in the INI file for each user and confirm all three with a single hash. This might also allow you to have the same username as an admin and as a non-admin with different passwords. A match to the hash for UsernamePasswordAdmin would be different than the hash for UsernamePasswordNormal. Just an idea. Also, if you make this a UDF file, be sure to have your functions return values like True/False (success/failure, use @extended for the reason it failed) or maybe 0 for success and various non-zero values to indicate why it failed instead of presenting success/fail MsgBoxes or calling functions. Let the user get back a simple yes/no and do with it what they want. If _Login() Then ; Login worked, do something EndIf