Leaderboard
Popular Content
Showing content with the highest reputation on 11/19/2021 in all areas
-
[NEW VERSION] 19 Nov 21 Added: The ability to set a specific icon on the dialog titlebar - either globally via a new parameter in _ExtMsgBoxSet or locally via the $vIcon parameter of _ExtMsgBox. New UDF and examples in the first post. M232 points
-
Extended Message Box - New Version: 16 Feb 24
hudsonhock reacted to Melba23 for a topic
Are you annoyed by the limitations of the standard Windows message dialog created by MsgBox? Would you like to have coloured backgrounds and text? To choose the justification and font? Do you want to be able to place the message box other than in the centre of the screen? Centred on your GUI, for example, or at a particular location on screen? What about having user-defined text on as many buttons as you need? And user-defined icons? Or a visible countdown of the timeout? Finally, would you like to choose whether the message box has a button on your already too-crowded taskbar? If the answer to any of these questions is "YES" then the ExtMsgBox UDF is for you! [NEW VERSION] 16 Feb 24 Changed: Some additional functionality added to the "TimeOut" parameter of _ExtMsgBox: - A positive integer sets the EMB timeout as before. - A negative integer will double the size of the countdown timer if it is used. - A colon-delimited string (eg: "10:5") will set the normal EMB timeout (first integer) and will also initially disable the EMB buttons for the required period (second integer). New UDF and examples in the zip. Older version changes: ChangeLog.txt As always, I realise nearly all of the DLL calls in these UDFs could be made by using commands in other UDFs like WinAPI.au3 - but as with all my UDFs (which you can find in my sig below) I am trying to prevent the need for any other include files. The UDF and examples (plus StringSize) in zip format: ExtMsgBox.zip Courteous comments and constructive criticisms welcome - guess which I prefer! M231 point -
To get the title or handle of the active window : HotKeySet("{ESC}", "_Terminate") HotKeySet("+!1", "_ActiveWindow") ; Shift-Alt-1 Global $sTitleActive, $hHandleActive ; Title or Handle While True Sleep(100) WEnd Func _ActiveWindow() $sTitleActive = WinGetTitle("[active]") $hHandleActive = WinGetHandle("[active]") MsgBox(BitOR(4096, 64), "Minimize :", "Title : " & @CRLF & $sTitleActive & @CRLF & _ "Handle : " & @CRLF & $hHandleActive & @CRLF) EndFunc Func _Terminate() MsgBox(BitOR(4096, 64), "Message :", "Script terminated" & @CRLF) Exit EndFunc Use WinSetState (with title or handle) to minimize the active window for example.1 point
-
Real-Time log file viewer
Earthshine reacted to ptrex for a topic
@Eathshine, Indeed there are many (free) tools available on the internet, for this type of logging. I don't know the use case of VAN0 ?1 point -
Works well on 2 advanced WD automation also with my capabilities UDF.1 point
-
@Jos The topic below, posted by @zeehteam, identified a slight flaw in the json_get and json_put functions as it relates to handling key names that are provided using a string. The regular expressions used to identify dot and bracket notations are a little too narrow. Basically, the current regular expressions do not allow valid key names that have embedded right brakets ("[") in them. Although such key names are odd and rare, they are valid. The attached json udf has slightly modified versions of json_get() and json_put() for your review. The only modification to the 2 functions is in how they identify and parse the notations in order to be more fully compliant with the standard. Basically, it assumes that there are 4 types of notations: Dot-notation using a literal value (ex. .name) Dot-notation using a string value (ex. ."name") Bracket-notation using a literal value (ex. [name]) Bracket-notation using a string value (ex. ["name"]) Indexes that are passed are correctly handled as bracket-notation using a literal (ex. [0]). To make it easier to maintain in the future, the only modifications to the 2 functions are at the very beginning where the notations are identified. The rest of the logic in json_get and json_put remained the same. The following example and output, using the modified functions, shows that the functions are correctly handling existing functionality and the ability to handle the new functionality. #AutoIt3Wrapper_AU3Check_Parameters=-w 3 -w 4 -w 5 -w 6 -d #include <Constants.au3> #include <MyIncludes\json\json (modified).au3> ;<== change to your location Const $JSON = _ '{ ' & _ ' "project": "Listing droids", ' & _ ' "version": "1.0", ' & _ ' "hasErrors": false, ' & _ ' "author": { ' & _ ' "name": "Luke", ' & _ ' "mail": "luke@2080.org" ' & _ ' }, ' & _ ' "[[[/script/droids]]]": [ ' & _ ' { ' & _ ' "name": "R2D2", ' & _ ' "type": "Astromecano", ' & _ ' "size": "0,96m" ' & _ ' }, ' & _ ' { ' & _ ' "name": "BB8", ' & _ ' "type": "Astromecano", ' & _ ' "size": "0,67m" ' & _ ' } ' & _ ' ] ' & _ '} ' json_example() Func json_example() Local $oJSON Local $Key, $Value $oJSON = Json_Decode($JSON) If @error Then Exit MsgBox($MB_ICONERROR + $MB_TOPMOST, "ERROR", "Decode error - @error = " & @error) ;Get values $Key = '."[[[/script/droids]]]"[0].name' $Value = Json_Get($oJSON, $Key) ConsoleWrite($Key & " = " & $Value & @CRLF) $Key = '["[[[/script/droids]]]"][0][name]' $Value = Json_Get($oJSON, $Key) ConsoleWrite($Key & " = " & $Value & @CRLF) $Key = '.author."name"' $Value = Json_Get($oJSON, $Key) ConsoleWrite($Key & " = " & $Value & @CRLF) $Key = '[author]["name"]' $Value = Json_Get($oJSON, $Key) ConsoleWrite($Key & " = " & $Value & @CRLF) ;Put values $oJSON = "" json_put($oJSON, '.description', "test json dataset") json_put($oJSON, '.author', "TheXman") json_put($oJSON, '."[[test]]"[0].name', "test name 1") json_put($oJSON, '."[[test]]"[0].number', 1) json_put($oJSON, '."[[test]]"[0].boolean', True) json_put($oJSON, '."[[test]]"[0].null_value', Null) json_put($oJSON, '["[[test]]"][1][name]', "test name 2") json_put($oJSON, '["[[test]]"][1][number]', 2.5) json_put($oJSON, '["[[test]]"][1][boolean]', False) json_put($oJSON, '["[[test]]"][1][null_value]', Null) ConsoleWrite(@CRLF) ConsoleWrite(Json_Encode($oJSON, $JSON_PRETTY_PRINT) & @CRLF) EndFunc Output ."[[[/script/droids]]]"[0].name = R2D2 ["[[[/script/droids]]]"][0][name] = R2D2 .author."name" = Luke [author]["name"] = Luke { "description": "test json dataset", "author": "TheXman", "[[test]]": [ { "name": "test name 1", "number": 1, "boolean": true, "null_value": null }, { "name": "test name 2", "number": 2.5, "boolean": false, "null_value": null } ] } Json (modified).au31 point
-
Look at FileFlush() You can flush file buffer to disk more frequently (if there are more FileWrites) and each of them including final FileClose() will take shorter time ...1 point
-
The Webdriver "actions" is an advanced feature that can be difficult to format correctly. In this case, the string of actions isn't properly formatted, so the Webdriver is throwing an error. Here's a simplified example that worked for me -- ; Press ctrl $sAction = '{"actions":[{"type": "key", "id": "keyboard_1", "actions": [{"type": "keyDown", "value": "\uE009"},' ; Pause $sAction &= '{"type": "pause", "duration": 500},' ; Press v $sAction &= '{"type": "keyDown", "value": "v"}, {"type": "keyUp", "value": "v"},' ; Release ctrl $sAction &= '{"type": "keyUp", "value": "\uE009"}]}]}' _WD_Action($sSession, "actions", $sAction)1 point
-
How to convert an Autoit project to C++ or python
argumentum reacted to RTFC for a topic
Yes, you can find it between your ears.1 point -
One solution would be to use the overlapped feature of the winapi related to files. https://docs.microsoft.com/en-us/windows/win32/sync/synchronization-and-overlapped-input-and-output This would be the proper way to async your file copy. Although it is not obvious...1 point
-
IMHO I think that this is NOT possible, because all what AutoIt does there is closing FileHandle, and the entire problem is strictly WindowsAPI + ComputerHardware (CPU+Drive) Performace, especially when AV software is watching file system in the background. unless.... This way should be possible with IPC UDF.1 point
-
You probably need to do a little search about color matching to define your own appreciation of what you're ready to consider "close enough" for your needs. Anyway and as just stated, colors you read are RGB values which, for elementary practice, can bee seen as a tridimensionnal space with coordinates bounded in [0..255], which is the so-called color-cube. The simplest way to estimate how close are two points in N-space is to compute their (Euclidean) distance. In your case, N=3 and if your pixels' colors, once split in Red, Green and Blue components, are: Local $pixel1[3] = [$r1, $g1, $b1] Local $pixel2[3] = [$r2, $g2, $b2] then the "simple" colorimetric distance separing them is: Local $ColorDist = Sqrt(($r2 - $r1) ^ 2 + ($g2 - $g1) ^ 2 + ($b2 - $b1) ^ 2) The smallest result you get, the closest the two colors are. The Sqrt() isn't even meaningful in your case so you can get along without it and without loosing any significance. In RGB space, the higher values are the most intense: black is {0, 0, 0} white is {255, 255, 255}. There are a large number of ways to appreciate and quantitize colors, but RGB is by far the simplest.1 point