Leaderboard

Totally unacceptable… I can’t even imagine the horror of having to convert expressions just because you decided to use a language written by some guy who negated before he expontiated. It’s an outrage and you should ask for a full refund.

As today I saw a @binbinhfr question here: I decide to post here this 2 following examples, which shows how to use GUICoordMode=2 + GUISetCoord() Simple example: #include <GUIConstantsEx.au3> Example() Func Example() Opt("GUICoordMode", 2) ; relative to cell mode GUICreate("My GUI Set Coord", 500, 200) GUISetCoord(20, 50) ; move the current anchor position to a precise point (20,50) GUICtrlCreateLabel("TESTING1", 0, 0, 75, 20) ; no previous control GUISetCoord(0, 0) ; move the current anchor position to a precise point (0,0) GUICtrlCreateLabel("TESTING2", -75, 0, 75, 20) ; takes account of previous control - relative to Right,Bottom corner of previously created GUICtrl*****() GUISetCoord(0, 0) ; move the current anchor position to a precise point (0,0) GUICtrlCreateLabel("TESTING3", -1, -1, 75, 20) ; does not take account of previous control (because used -1,-1 as left,Top parameters) GUISetState() While 1 Switch GUIGetMsg() Case $GUI_EVENT_CLOSE ExitLoop EndSwitch WEnd EndFunc ;==>Example More complex/complicated/advance example: #include <ColorConstants.au3> #include <FontConstants.au3> #include <GUIConstantsEx.au3> Example() Func Example() GUICreate("My GUI Set Coord", 500, 500) Opt("GUICoordMode", 1) ; (default) absolute coordinates still relative to the dialog box. #Region - draw background Local $iCorner = 10 GUICtrlCreateLabel("0", 100 - $iCorner, 100 - $iCorner, 100 + $iCorner * 2, 100 + $iCorner * 2) GUICtrlSetBkColor(-1, $COLOR_BLACK) GUICtrlSetFont(-1, 20, $FW_BOLD) #EndRegion - draw background Opt("GUICoordMode", 2) ; relative to cell mode #Region - MOVE ANCHOR + RESETING OFFSET GUISetCoord(0, 0) ; move the current anchor position to a precise point (0,0) GUICtrlCreateLabel("", -1, -1, 0, 0) ; reseting offset GUICtrlSetBkColor(-1, $COLOR_BLACK) #EndRegion - MOVE ANCHOR + RESETING OFFSET GUICtrlCreateLabel("1", 100, 100, 100, 100) ; anchor 0,0 moved 100,100 offset = 100,100 Right,Bottom corner = 0+100+100,0+100+100 GUICtrlSetBkColor(-1, $COLOR_AQUA) GUICtrlSetFont(-1, 20, $FW_BOLD) GUICtrlCreateLabel("2", 0, -100, 100, 100) ; anchor 200,200 moved 0,-100 offset = 100,100 Right,Bottom corner = 200+0+100,200-100+100 GUICtrlSetBkColor(-1, $COLOR_RED) GUICtrlSetFont(-1, 20, $FW_BOLD) GUICtrlCreateLabel("3", -200, 0, 100, 100) ; anchor 300,200 moved -200,0 offset = 100,100 Right,Bottom corner = 300-200+100,200+0+100 GUICtrlSetBkColor(-1, $COLOR_GREEN) GUICtrlSetFont(-1, 20, $FW_BOLD) GUICtrlCreateLabel("4", -200, -200, 100, 100) ; anchor 200,300 moved -200,-200 offset = 100,100 Right,Bottom corner = 200-200+100,300-200+100 GUICtrlSetBkColor(-1, $COLOR_OLIVE) GUICtrlSetFont(-1, 20, $FW_BOLD) GUICtrlCreateLabel("5", 0, -200, 100, 100) ; anchor 100,200 moved 0,-200 offset = 100,100 Right,Bottom corner = 100+0+100,200-200+100 = 200,100 ;~ GUICtrlSetBkColor(-1, $COLOR_MEDGRAY) GUICtrlSetBkColor(-1, $COLOR_ORANGE) GUICtrlSetFont(-1, 20, $FW_BOLD) #Region - MOVE ANCHOR GUISetCoord(-100, -100) ; move the current anchor position to a precise point (-100,-100) + prev offset 100,100 GUICtrlCreateLabel("6", 25, 25, 50, 50) ; anchor 0,0 moved 25,25 offset = 50,50 Right,Bottom corner = 75,75 GUICtrlSetBkColor(-1, $COLOR_BLUE) GUICtrlSetFont(-1, 20, $FW_BOLD) #EndRegion - MOVE ANCHOR GUISetState() While 1 Switch GUIGetMsg() Case $GUI_EVENT_CLOSE ExitLoop EndSwitch WEnd EndFunc ;==>Example btw. I want to thanks @Danyfirex and @Nine for the feedback they gave back in September when we discussed it in the background.

ConsoleWrite("Exit is crazy"^0 & @CRLF)

Konrad-Franz, Welcome to the AutoIt forum. As a programmer of some 50+ years experience I would never rely on operator precedence in any mathematical expression and would always use parentheses to make the order explicit. While this may make the original formulation of the expression slightly more onerous, the advantages of not having to rely on the arbitrary operator precedence (amply shown in the post above) of the various programming languages that might be used to evaluate it far outweigh this minor inconvenience. M23

Depends, do you mean how many times the script has been run or how many times during a single session? If you want to count the number of times a script has run you would have to write it to either registry or to a file for example an ini. Examples: ;~ Example 1 - Script Run Count Global $g_iRunCount = IniRead(@ScriptDir & "\Script.ini", "General", "Count", 1) $g_iRunCount += 1 ;~ Do stuff here ;~ Exiting script IniWrite(@ScriptDir & "\Script.ini", "General", "Count", $g_iRunCount) ;~ Example 2 - Function Count Global $g_iFuncCount = 0 MsgBox(0, "Start Function Count", "Run " & $g_iFuncCount & " times.") For $i = 1 To 10 _Example() Next MsgBox(0, "End Function Count", "Run " & $g_iFuncCount & " times.") Func _Example() $g_iFuncCount += 1 ;~ Do stuff Sleep(100) EndFunc

@binbinhfr take a look here:

No fun, just an ascertainment - please read post #1 again

Memory read using Ptr this for string don't know how to pass Object and Array using this technique. example on Object and Array using this technique from fellow Autoit member would be nice . below code(by @Ascer) taken from this thread https://www.autoitscript.com/forum/topic/192339-reading-memory-double/?do=findComment&comment=1381902 Main.au3 Local $otext = "How are You?" Local $o_PID = WinGetProcess("AutoIt v3") Local $o_Buffer = "char[" & StringLen($otext) + 1 & "]" Local $o_Struct = DllStructCreate($o_Buffer) Local $o_Ptr = DllStructGetPtr($o_Struct) ;~ SetData DllStructSetData($o_Struct, 1, $otext) ; Start client RunWait( @AutoItExe & " /AutoIt3ExecuteScript " & '"Client.au3" ' & $o_PID & " " & $o_Buffer & " " & $o_Ptr) $o_Struct = 0 Client.au3 MsgBox( 0, "Client", "Client.... Started" ) Local $t_Pid = Number($CmdLine[1]) Local $t_Buffer = $CmdLine[2] Local $t_Address = Number($CmdLine[3]) Local $hHandle = DllCall("kernel32.dll", 'int', 'OpenProcess', 'int', 0x1F0FFF, 'int', 1, 'int', $t_Pid) If @error Then MsgBox( 0, "Client", "+++ Failed to open process memory for FULL_ACCESS. Error is " & @error ) Exit EndIf Local $sStruct = DllStructCreate($t_Buffer) If @error Then MsgBox( 0, "Client", "+++ Failed to create $sStruct. Error is " & @error ) Exit EndIf DllCall("kernel32.dll", 'int', 'ReadProcessMemory', 'int', $hHandle[0], 'int', $t_Address, 'ptr', DllStructGetPtr($sStruct), 'int', DllStructGetSize($sStruct), 'int', '') If @error Then MsgBox( 0, "Client", "+++ Failed to Read Process Memory. Error is " & @error ) Exit EndIf Local $vRet = DllStructGetData($sStruct, 1) If @error Then MsgBox( 0, "Client", "+++ Failed to Get data from $sStruct. Error is " & @error ) Exit EndIf MsgBox( 0, "Client", $vRet ) MsgBox( 0, "Client", "Client.... End" )

It doesn't work that way. Using SQLite and with or without any OS-layer encryption it'll always work like this: App start open DB while app duration read DB [the engine determines which pages it should read in order to locate the row(s) you want and fetch them] update DB [the engine determines which pages it should read in order to locate the row(s) you want, then fetch, change and rewrite changed pages] write DB [the engine determines which pages it should change/add in order to add/delete what you want, then fetch, change and rewrite changed pages] wend close DB app termination The encryption/decryption of data is done transparently by the OS/driver at the page/cluster level. There is zero difference between using an unencrypted DB, an encrypted DB placed on an OS-layer encrypted volume. Using system.data.sqlite with an encrypted DB placed on an unencrypted volume the only thing you have to do is issue a new step at 2.5 sending a pragma to supply the encryption key. Note that you can add that step in all 3 cases since this pragma is ignored when the DLL has no support for encryption. In the last case it's however your responsability to manage the encryption key, while in the 2 former cases your OS credentials can do that for you with good level of security.

Wouldn't it be something like: Local $hRun2 = _Run('notepad.exe', 0, 0, @DesktopWidth,@DesktopHeight/3) Local $hRun1 = _Run('notepad.exe', 0,@DesktopHeight/3,@DesktopWidth,@DesktopHeight/3 * 2) Func _Run($sRunCommand, $iX, $iY, $iW, $iH) Local $aWinList_Before = WinList("[CLASS:Notepad]") Run($sRunCommand) Do $aWinList_After = WinList("[CLASS:Notepad]") Until $aWinList_After[0][0] > $aWinList_Before[0][0] Local $hWnd = $aWinList_After[1][1] Sleep(1000) WinMove($hWnd, "", $iX, $iY, $iW, $iH) EndFunc

Have you checked out KPScript? I have a script for wrapping some KPScript commands in AutoIt functions, but most people hardcode them. Personally, I wouldn't store passwords in anything I've written because I don't trust myself to catch all the bugs. On the other hand, if it's a personal application on your personal device, I completely understand and I've even stored passwords in the scripts before

Yes I answered a bit hastily! Yet I prefer typing defensively with potentially ambiguous constructs. At least in Mma, we have the possibility to decide precedence, associativity, distributivity, ... of every user function.

Based on your own link : Unary minus sign There are differing conventions concerning the unary operator − (usually read "minus"). In written or printed mathematics, the expression −32 is interpreted to mean −(32) = − 9.[1][19] In some applications and programming languages, notably Microsoft Excel, PlanMaker (and other spreadsheet applications) and the programming language bc, unary operators have a higher priority than binary operators, that is, the unary minus has higher precedence than exponentiation, so in those languages −32 will be interpreted as (−3)2 = 9.[20] This does not apply to the binary minus operator −; for example in Microsoft Excel while the formulas =−2^2, =-(2)^2 and =0+−2^2 return 4, the formula =0−2^2 and =−(2^2) return −4. There are different conventions. If we change it to your preference, someone else will complain that it does not follow Excel and other languages. It is a "dam if you do, dam if you don't" dilemma.

@junkew: it seems indeed to be a scaling problem: when I move mousecursor to a button above or below "Next", and press 'control +w' to acivate simplespy, the red rectangle moves accordingly. However, I got the precompiled version of LabelImg running by deleting a file in the user folder (https://github.com/tzutalin/labelImg/issues/221#issuecomment-368237423). In this version, the mouseclick works just fine - just as well as sending 'd', which is a builtin hotkey for "Next image" in LabelImg. So with this, my problem is solved. Thank you very much for your efforts! I really appreciate it.

Check out : CommandLine EDIT : For testing purposes, e.g. during development, you can also specify parameters within the SciTE-Editor-->,press SHIFT-F8.

Code Fixed: Mode 1: #include <File.au3> $file = "c:\yourfile.txt" FileOpen($file, 0) For $i = 1 to _FileCountLines($file) $line = FileReadLine($file, $i) msgbox(0,'','the line ' & $i & ' is ' & $line) Next FileClose($file) Mode 2: #include <file.au3> $file = FileOpen("yourfile.txt", 0) While 1 $line = FileReadLine($file) If @error = -1 Then ExitLoop MsgBox(0,'',$line) WEnd FileClose($file) Mode 3: #include <Array.au3> #include <File.au3> Local $aInput $file = "yourfile.txt" _FileReadToArray($file, $aInput) For $i = 1 to UBound($aInput) -1 MsgBox (0,'',$aInput[$i]) Next all tested!