Leaderboard

Found the issue Original ArrayDisplayInternals.au3 (version 3.3.14.5) lines #560 to #563 : If Not IsHWnd($hWnd) Then $hWnd = GUICtrlGetHandle($hWnd) ;~ Local Const $LVM_GETHEADER = (0x1000 + 31) ; 0x101F Local $hHeader = HWnd(GUICtrlSendMsg($hWnd, 0x101F, 0, 0)) Move line #560 just below the 2 others : ;~ Local Const $LVM_GETHEADER = (0x1000 + 31) ; 0x101F Local $hHeader = HWnd(GUICtrlSendMsg($hWnd, 0x101F, 0, 0)) If Not IsHWnd($hWnd) Then $hWnd = GUICtrlGetHandle($hWnd) Now the sort arrow will be displayed when you sort on any column

It's about running exe from memory as it's often called. So you have some binary data that you want to embed in your script and run afterward like some additional program. In this post I will try to explain how to do it. First to deal with mentioned binary as that's, in spite of the plainness of retrieving it, often insuperable. To avoid questions about that this is one way of getting it: Global $sModule = "E:Program filesGUIDGenGUIDGEN.EXE" ; change to yours wanted Global $hModule = FileOpen($sModule, 16) If @error Then Exit Global $bBinary = FileRead($hModule) FileClose($hModule) Global Const $MAX_LINESIZE = 4095 Global $iNewLine, $j Global $iChinkSize = 32 Global $sBinary For $i = 1 To BinaryLen($bBinary) Step $iChinkSize $j += 1 If 4*($j * $iChinkSize) > $MAX_LINESIZE - 129 Then $iNewLine = 1 EndIf If $iNewLine Then $iNewLine = 0 $j = 0 $sBinary = StringTrimRight($sBinary, 5) $sBinary &= @CRLF & '$bBinary &= "' & StringTrimLeft(BinaryMid($bBinary, $i, $iChinkSize), 2) & '" & _' & @CRLF ContinueLoop EndIf If $i = 1 Then $sBinary &= '$bBinary = "' & BinaryMid($bBinary, $i, $iChinkSize) & '" & _' & @CRLF Else $sBinary &= ' "' & StringTrimLeft(BinaryMid($bBinary, $i, $iChinkSize), 2) & '" & _' & @CRLF EndIf Next $sBinary = StringTrimRight($sBinary, 5) ClipPut($sBinary) ConsoleWrite($sBinary)Now for what's really important... Executable file causes a computer to perform indicated tasks according to encoded instructions. Files that we talk about are in PE format. When exe file is run special loader reads it and performs act of loading. That's how that particular exe gets in touch with a processor. Processor then executes different actions described by the opcodes. Main requirement for any PE file required by the loader is for it to actually exist. To be written on the drive. It can't be in the air. That's not allowed and when you think of it it's only logical. So how to run from memory? I'm gonna fool the system. It will think that all works as it should and will have no idea that it plays my game. There is more than way of doing that. Method described here has been used by different peoples before. When doing research for this post I have encountered many implementations. And I must say that I was very disappointed seeing that even the writers of the code often lack understanding of it. It's kind of pathetic when you see some code used and when asking author what's this or that you get answer "I don't know". And if you ask for the code to be explained by words (any fucking human language) coders fail terribly. How can you write code if you can't explain it?!? Anyway, this is the procedure: Start your script Create new process using CreateProcess function with CREATE_SUSPENDED flag Use GetThreadContext function to fill CONTEXT structure Read and interpret passed binary Allocate enough memory for the new module inside the victim process Simulate loader. Construct the new module (load) in place of allocated space. Make use of mentioned CONTEXT structure. Change entry point data and ImageBaseAddress data. Resume execution If all that went well windows should now be running not the original module but the new, saved in script as a variable. The script: RunBinary.au3 Script is well commented so it shouldn't be too hard to get a grip. New script is taking all possible advantages of PE format. That means if your module (embedded) has relocation directory it will run for sure.If not it could fail. When it will fail? Modules with no reloc directory (IMAGE_DIRECTORY_ENTRY_BASERELOC) ought to be loaded at precise address (stored within module; IMAGE_OPTIONAL_HEADER ImageBase). If for some reason not enough space can be allocated at that address within victim's memory space, function will fail. Thing is system makes rules, if we are not allowed to some memory space of a process there is nothing to do then to try again. So, try again if it fails. Maybe change the 'victim'. edit: 64bit support added. That means you can embed either x64 or x86 modules. If your AutoIt is x64 you embed x64 modules. If AutoIt is x86 embed x86. x64 AutoIt could also use embedded x86 modules but I don't like that because needed structures would have to be changed to something that's not meeting aesthetics standards .

try : $oIE.visible = False

Hi @NassauSky Your question seems confusing to me as you mention memory usage and output file as if they are the same? Anyway the memory thing is pretty easy to explain _HTMLParser2 uses the _TokenList_CreateToken. It in turn allocates memory that AutoIt does not clear automatically (via _MemGlobalAlloc). This is done to allow dllstruct references within dllstructs without holding a variable with all dllstructs to prevent AutoIt from freeing the memory when the variable gets unset. Also the tokenlist never get cleared, so i guess you were still talking about memory when you mentioned "appending" to the output, i guess? Clearing the tokenList is easy, freeing the memory held by the tokenlist hovever requires a loop and some code: Func TokenList_Clear() Local $tList = $__g_tTokenListList Local $tToken Local $hToken = $tList.First While Not $hToken = 0 $tToken = DllStructCreate($tagTokenListToken, $hToken) $tToken = $tToken.Next _MemGlobalFree($hToken) $hToken = $tToken WEnd $tList.First = 0 $tList.Last = 0 EndFunc Just call it between _Pretty calls like this: _Pretty() TokenList_Clear() _Pretty() Hope this helps

@NassauSky According to the W3C specs, the webdriver will automatically scroll the element into view when doing things like click it, setting its value, etc. If you need to manually scroll an element into view, then see my earlier response here --

ByRef is needed when you want to change passed variable back, or when you passing realy long, big data as parameters. So why you need Const ByRef in your scenario ?