Leaderboard

I've tested to beta installer and am happy to report that no issues were encountered. Thanks for the continued support, Jos.

Change history. These are the settings: which I have defaulted to these in SciTEGlobal.properties: change.history=7 indicator.saved.insertion=style:Hidden indicator.saved.deletion=style:Hidden #~ change.history=3 #~ indicator.reverted.to.origin.insertion=style:squiggle,colour:#40A0BF #~ indicator.reverted.to.origin.deletion=style:point,colour:#40A0BF #~ indicator.saved.insertion=style:squiggle,colour:#60A060 #~ indicator.saved.deletion=style:point,colour:#00A000 #~ indicator.modified.insertion=style:squiggle,colour:#A0A060 #~ indicator.modified.deletion=style:point,colour:#A0A000 #~ indicator.reverted.to.modified.insertion=style:squiggle,colour:#FF8000 #~ indicator.reverted.to.modified.deletion=style:point,colour:#FF8000 #~ marker.reverted.to.origin=style:leftrect,fore:#40A0BF,back:#40A0BF #~ marker.saved=style:leftrect,fore:#00A000,back:#00A000 #~ marker.modified=style:leftrect,fore:#A0A000,back:#A0A000 #~ marker.reverted.to.modified=style:leftrect,fore:#FF8000,back:#FF8000 I noticed that the SciTE4AutoIt3 helpfile didn't contain the latest SciTE Docs so updated that in the Installer & Zip file. Version remained the same. Also changed default change.history from 5 to 7 to also show the change markers at the left side, right from the linenumbers.

Hello, When using an Edit widget, I need to tell if the user hit CTRL+F (to launch a new search) or F3 (to resume searching, in case the same string occurs more than once). GUICtrlCreateDummy() + GUISetAccelerators() does the job, but I was wondering if there's a way to go through the Edit widget instead and tell what keys were hit. #Region ### START Koda GUI section ### Form= $Form1 = GUICreate("Form1", 689, 540, 286, 121) $Edit1 = GUICtrlCreateEdit("", 0, 0, 688, 539,BitOR($ES_WANTRETURN, $ES_MULTILINE, $WS_VSCROLL, $ES_AUTOVSCROLL,$ES_READONLY)) ;Two IDs to tell which keys were pressed: CTRL+F or F3? Local $IdSearch = GUICtrlCreateDummy() Local $IdF3 = GUICtrlCreateDummy() ;Local $aAccelKeys[2][2] = [["^f", $Edit1],["{F3}", $Edit1]] Local $aAccelKeys[2][2] = [["^f", $IdSearch],["{F3}", $IdF3]] GUISetAccelerators($aAccelKeys) GUISetState(@SW_SHOW) #EndRegion ### END Koda GUI section ### While True     $nMsg = GUIGetMsg()     Switch $nMsg         Case $IdSearch             MsgBox($MB_OK, "$IdSearch", "$IdSearch")         Case $IdF3             MsgBox($MB_OK, "$IdF3", "$IdF3")         Case $Edit1 ;How to check if user pressed CTRL+F or F3?             ExitLoop             ;Case CTRL+F             Local $sSearch = InputBox ( "Search", "Search for")             if not @error Then                 SearchInEdit ($Edit1,$sSearch,$searchInEditStartingPos)             EndIf             ;Case F3: Get current location, and search further         Case $GUI_EVENT_CLOSE             Exit     EndSwitch WEnd Thank you.

SyncFiles v0.9.0 Here is my take on a file/folder comparison and synchronization tool. There are a lot of these out there already, but surely one more wouldn't hurt! This has been a fun one; I've learned so much more than I ever thought I would when starting this project. I hope you enjoy it! Key Features: Analyze the contents of two folders to detect any differences between the files' dates and sizes Display the results in a color-coded list Synchronize the two folders; select one of three options: Synchronize: Copy new and updated files in either direction Mirror to left: Make the left folder identical to the right folder Mirror to right: Make the right folder identical to the left folder Save and switch between multiple sync profiles Progress bar to show sync percent completed Drag and drop folders onto the input boxes Works with UNC file paths: "\\sharepoint.company.com@SSL\DavWWWRoot\Projects\ProjectDocuments" Right click on any file to override the sync action Download v0.9.0 (2022-08-19) SyncFiles_0.9.0.zip Or check the GitHub Repository for the latest updates. I spent a lot of time testing many different ways to search, compare, and copy files. The speed as it is now in my opinion is quite acceptable, but I will continue investigating more ways to increase the search and analyze speed. If I can muster the necessary brainpower, I may look into LarsJ's fast array functions or some custom C++/ASM functions to improve the speed or maybe spawning child processes to spread the load. Credits: LarsJ: example of virtual listviews and item colors [Link] Yashied: Copy UDF [Link] Ward: MemoryDll UDF (and BinaryCall UDF) [Link] Ward: Json UDF [Link] kurtykurtyboy (me): GuiFlatButton UDF [Link] Many other random snippets from the forums

EDIT: code is faulty. Use code from @mistersquirrle below! Parsing a numérical expression and computing its numerical value while interpreting standard multiplier acronyms isn't hard: Local $sExpr = "1.7G +3.5k*(6.2 + 3d - 2a + 4.8µ - 4da) / 2m" _Normalize($sExpr) ConsoleWrite($sExpr & @LF) Local $nRes = Execute($sExpr) ConsoleWrite($nRes & @LF) Func _Normalize(ByRef $s) Local Static $aSuffixes = [ _ ["y", -24], ["z", -21], ["(?<!d)a", -18], ["f", -15], ["p", -12], ["n", -9], ["µ", -6], ["m", -3], ["c", -2], ["d(?!a)", -1], _ ["da", 1], ["h", 2], ["k", 3], ["M", 6], ["G", 9], ["T", 12], ["P", 15], ["E", 18], ["Z", 21], ["Y", 24] _ ] For $i = 0 To UBound($aSuffixes) - 1 $s = StringRegExpReplace($s, $aSuffixes[$i][0], "*1e" & $aSuffixes[$i][1]) Next EndFunc Notice that kilo is k (lowercase) and micro is µ not u. EDIT: added centi, deci, deca and hecto suffixes.

... @Ontosy bumped the question and I gave an answer. If @Aether ever comes back, well, there's an answer

@argumentum VERY NICE!!! I knew it had to do with the datatype and tried all I could think of. But not "BinaryToString" while including the "0x" prefix. Thank you for taking the time. You made my day. taurus905

I doubt the op is still looking for a solution 3 years later guys. But you never know.

#cs ---------------------------------------------------------------------------- AutoIt Version: 3.3.15.5 (Beta) Author: myName Script Function: Template AutoIt script. #ce ---------------------------------------------------------------------------- ; Script Start - Add your code below here #include <ComboConstants.au3> #include <Crypt.au3> #include <EditConstants.au3> #include <GUIConstantsEx.au3> #include <StringConstants.au3> #include <WinAPIConv.au3> #include <WindowsConstants.au3> Global $g_iAlgorithm = $CALG_SHA_256, $g_idInputEdit = -1, $g_idOutputEdit = -1 Example() Func Example() Local $hGUI = GUICreate("Realtime Hashing", 400, 320) $g_idInputEdit = GUICtrlCreateEdit("", 0, 0, 400, 150, $ES_WANTRETURN) $g_idOutputEdit = GUICtrlCreateEdit("", 0, 150, 400, 150, $ES_READONLY) Local $idCombo = GUICtrlCreateCombo("", 0, 300, 100, 20, $CBS_DROPDOWNLIST) GUICtrlSetData($idCombo, "MD2 (128bit)|MD4 (128bit)|MD5 (128bit)|SHA1 (160bit)|SHA_256|SHA_384|SHA_512", "SHA_256") GUIRegisterMsg($WM_COMMAND, "WM_COMMAND") GUISetState(@SW_SHOW, $hGUI) _Crypt_Startup() ; To optimize performance start the crypt library. Local $dHash = 0, _ $sRead = BinaryToString("0x2625E615A69CB0B897EE8685022F9710F1BE324612B4907F557548EB3D189925") GUICtrlSetData($g_idInputEdit, $sRead) $dHash = _Crypt_HashData($sRead, $g_iAlgorithm) ; Create a hash of the text entered. GUICtrlSetData($g_idOutputEdit, $dHash) ; Set the output box with the hash data. While 1 Switch GUIGetMsg() Case $GUI_EVENT_CLOSE ExitLoop Case $idCombo ; Check when the combobox is selected and retrieve the correct algorithm. Switch GUICtrlRead($idCombo) ; Read the combobox selection. Case "MD2 (128bit)" $g_iAlgorithm = $CALG_MD2 Case "MD4 (128bit)" $g_iAlgorithm = $CALG_MD4 Case "MD5 (128bit)" $g_iAlgorithm = $CALG_MD5 Case "SHA1 (160bit)" $g_iAlgorithm = $CALG_SHA1 Case "SHA_256" $g_iAlgorithm = $CALG_SHA_256 Case "SHA_384" $g_iAlgorithm = $CALG_SHA_384 Case "SHA_512" $g_iAlgorithm = $CALG_SHA_512 EndSwitch $sRead = GUICtrlRead($g_idInputEdit) If StringStripWS($sRead, $STR_STRIPALL) <> "" Then ; Check there is text available to hash. $dHash = _Crypt_HashData($sRead, $g_iAlgorithm) ; Create a hash of the text entered. GUICtrlSetData($g_idOutputEdit, $dHash) ; Set the output box with the hash data. EndIf EndSwitch WEnd GUIDelete($hGUI) ; Delete the previous GUI and all controls. _Crypt_Shutdown() ; Shutdown the crypt library. EndFunc ;==>Example Func WM_COMMAND($hWnd, $iMsg, $wParam, $lParam) #forceref $hWnd, $iMsg, $lParam Switch _WinAPI_LoWord($wParam) Case $g_idInputEdit Switch _WinAPI_HiWord($wParam) Case $EN_CHANGE Local $dHash = _Crypt_HashData(GUICtrlRead($g_idInputEdit), $g_iAlgorithm) ; Create a hash of the text entered. GUICtrlSetData($g_idOutputEdit, $dHash) ; Set the output box with the hash data. EndSwitch EndSwitch EndFunc ;==>WM_COMMAND ..you're welcome

Just a little off-topic remark and only FYI: I see that there is an issue in the current au3lexer and it doesn't do correct syntax highlighting for these: The lexer should not recognize them as Start/Stop of commentblocks and should simply be colored as some PREPROCESSOR statement. Will be fixed.

Hi all Thanks for the answers so far! So i think i will go with the AB solution. I agree that most if not all people will use multi-line comments, where the text content always starts at line two in the block (me included). It does make the most sense. But from a parser perspective, all content after the #cs, and before the #ce that works in the native AutoIt3 executable should be included. I can see why you think that, bout my current parser needs to be a one to one implementation of the parser rules AutoIt version 3.3.14.5 uses. I apologize that i did not make clear what my current target AutoIt version was. I do plan to make parsers for future AutoIt3 versions also, but choose 3.3.14.5 as my starting point. If they "patch" the multi-line syntax in a later version, that specific parser implementation will of course reflect that I thank you all! You have saved me days of time wasted on this "simple" implementation choice