guestscripter

https://www.autoitscript.com/forum/applications/core/interface/file/attachment.php?id=48056

You're going in the right direction I think by how you are considering usage of your $marker variabl. The main thing you need to do is use the Returned Data in $marker from the _ImageSearch function to change the starting points for the next search on every loop after every previous result. Only on the first search do you want the search to begin at 0,0 which are your $yy and $$xx variables. You want to update those variables after every previous result. You're gonna get in twouble here if that's game automation related, tss tss tss Don't have the time right now to write or test any actual script for you but I hope the idea is clearer now

Have tried and failed at finding a solution myself. Crazy idea though; maybe it could be done. If the "minimized" window is actively being rendered on a pseudo external monitor, i.e. not in focus and not physically visible by the user, so the same thing as minimized. This is going to be difficult to make write as a script, but it's the only possibility with potential, if somebody would want to try. The important thing is that your System and Windows and the GUI should think that the GUI is visible, although it isn't...

The way you describe what you are trying to do it's difficult to understand what the purpose should be. It would help if you give some examples with what the inputs would be and what the output should be. I played around with your script to make it work, just it's kind of pointless the way it is, since your conditions ("1st input contains c and not b" etc.) only allow for one result "car". #include <ButtonConstants.au3> #include <EditConstants.au3> #include <GUIConstantsEx.au3> #include <WindowsConstants.au3> $Word1 = "car" $Word2 = "cat" $Word3 = "cee" $Word4 = "bar" $Word5 = "bat" Local $11 = "c", $12 = "b" Local $21 = "a", $22 = "b" Local $31 = "r", $32 = "t" #Region ### START Koda GUI section ### Form= $Form1 = GUICreate("Form1", 364, 259, 192, 114) $Input1 = GUICtrlCreateInput("cxx", 16, 24, 121, 21) $Input2 = GUICtrlCreateInput("axx", 16, 72, 121, 21) $Input3 = GUICtrlCreateInput("rxx", 16, 112, 121, 21) $Button1 = GUICtrlCreateButton("GO!", 24, 168, 97, 65) $Edit1 = GUICtrlCreateEdit("", 192, 24, 129, 217, BitOR($GUI_SS_DEFAULT_EDIT, $ES_CENTER)) GUICtrlSetData(-1, "Edit1") GUISetState(@SW_SHOW) #EndRegion ### END Koda GUI section ### ControlClick($Form1,"",$Button1);Autoclick button on startup While 1 $nMsg = GUIGetMsg() Switch $nMsg Case $GUI_EVENT_CLOSE Exit Case $Button1 ; Check if $Input1 has a "c" or a "b" in it ; If $Input1 has a "c" and not a "b" it will check $Input2 and see if it has an "a" or an "e" in it. If (StringInStr(GUICtrlRead($Input1), $11) > 0) And (Not (StringInStr(GUICtrlRead($Input1), $12) > 0)) Then ; If $Input2 has an "a" and not an "e" in it, it will continue to $Inputbox3 and check if it has an "r" or a "t". If (StringInStr(GUICtrlRead($Input2), $21) > 0) And (Not (StringInStr(GUICtrlRead($Input2), $22) > 0)) Then ; If Input3 has an "r" and not a "t" it should find out which word listed above matches with the word spelled out in the inputboxes. If (StringInStr(GUICtrlRead($Input3), $31) > 0) And (Not (StringInStr(GUICtrlRead($Input3), $32) > 0)) Then $sCombination = $11 & $21 & $31 $sWordsMatch = "" If $sCombination = $Word1 Then $sWordsMatch &= $Word1 & @CRLF If $sCombination = $Word2 Then $sWordsMatch &= $Word2 & @CRLF If $sCombination = $Word3 Then $sWordsMatch &= $Word3 & @CRLF If $sCombination = $Word4 Then $sWordsMatch &= $Word4 & @CRLF If $sCombination = $Word5 Then $sWordsMatch &= $Word5 & @CRLF GUICtrlSetData($Edit1, $sWordsMatch);Data is the words listed above that match the input from the inputboxes. EndIf EndIf EndIf EndSwitch WEnd I'm confused and slightly curious as to the point, so let us know!

You're trying to solve anagrams, right?

For ControlClick (and ControlSend) there's a trick: You want the window $handle as the title (you did that already) and in case you don't have a specific control, also the controlID part as the window $handle (you left it empty as "") That may just fix it for you, I hope it helps :-) Also check the coordinates you are clicking maybe. Careful about absolute vs. window coordinates etc. etc. $hWin = WinGetHandle("Q-MATIC Monitor™ 3") ControlClick($hWin, "", $hWin, "Left", 1, 92, 57)

Or as a quick, simple and rough fix, PixelCheckSum....

If the "Autoit Window Info" tool really can't find the button, and alternatives to this tool (WinSpy++ is one of the names I think I remember) don't either, _ImageSearch() could help you, but we warned if you go in this direction different screen resolutions etc. etc. may become a hassle on different computers.

Benefit of posting in the Forum vs in the Wiki: Feedback, Appreciation, Comments, Update Notifications per E-Mail... IMHO maybe there could be a "Snippets 2015", "Snippets 2015" Thread in the forum, or maybe even "Snippets November 2015" etc. then it never gets much too long... Personally I like checking out new posts in this thread. Just wanted to give some counter arguments to the above.

Alright so this gives me more useful info on understanding what's going on in terms of events... especially this part I didn't know about before; http://stackoverflow.com/questions/10213703/how-do-i-view-events-fired-on-an-element-in-chrome-web-developer Now what I could really use help with is learning how to manipulate/stop/pause these events manually.... any tips much appreciated!

https://www.autoitscript.com/forum/topic/161333-_newiecreatepseudoembedded-create-embedded-ie-frame-with-latest-ie-version I think this is what you need.

Hi, I've been tinkering and tinkering and I really hope someone can give me some advice. I've used the IE.au3 UDF successfully with some different scripts, just I'm not even sure I'm going in the right direction on this one. A bunch of text input fields on a secure site are to be updated with data in the script (which the script gets from an excel file), and submitted. Not too hard, right? The input fields html looks like this: (in this case current value is 777.00) <input id="pt1:r1:1:pt1:ghostText:i10:0:lvl2:0:lvl3:0:lvl3PrcHdr:i15:0:lvl3Prc:ot21::content" name="pt1:r1:1:pt1:ghostText:i10:0:lvl2:0:lvl3:0:lvl3PrcHdr:i15:0:lvl3Prc:ot21" class="x25" type="text" value="777.00" title="777.00">I've tried _IEFormElementSetValue($oObj, $sInput, 0) _IEFormElementSetValue($oObj, $sInput, 1) $oObj.setAttribute("value", $sInput) $oObj.setAttribute("title", $sInput) _IEAction($oObj, "focus") $oObj.fireEvent("onfocus")in various combinations and orders, and the trouble is always that some fields are "skipped" or revert back to their previous value a few seconds later. Even though not actually submitting ie. clicking the "Save Changes" button on the page, some kind of processing is already going when anything is changed/focused etc., as far as I can see. What else I have tried: Using ControlSend($g_oIEHandle, "", "[CLASSNN:Internet Explorer_Server8]", $sInput) in combination with a lot of MouseGetCursor() I have a more simple script roughly "working" (doesn't use any IE objects). It works by waiting for a normal mousecursor for the page to be "ready" again in between inputfields... ...and this ends up being very slow and not much faster than human entry, and "only" fails sometimes (which is why there is a checking function as well, though this also adds to the time taken). So what can I do? From some research I've done, I understand there may be some way to cancel events (I know as much as that events have a propery "cancelable"). Maybe we can stop any javascript function from being called while filling all the input fields somehow, so that none of the input gets lost.Could this help? How to do this? One other idea is with POST and GET, so that the data that is usually submitted to the site on "Save Changes" can be sent without interface interaction... would this probably be very difficult to attempt? Where to start? (https...) Please, any thoughts, guidance on the above, or ideas/approaches I haven't thought of?

Hey I really like your UDF! It's bringing me forward a lot with my script, one "enhancement" maybe you could find time for, that would be great: I have for example this (potential) Xpath (works in Chrome) Const $xpath_last_offset = '//*[@id="search_results_table"]/div[@class="results-paging"]/ul/li[last()]/a'and as far as I can see the part that isn't working through the UDF is the xyz[last()] bit. I've been scanning over, among others, the https://en.wikipedia.org/wiki/XPath page, being a beginner with Xpath, and one part addresses this: I'm getting the impression that there may be a workaround to using last(), it's just all still quite over my head, thus the use of your great (if not perfect i.e. a work in progress) UDF. So I just wanted to give my compliments, and ask if you could put it on the to-do list, and/or give me a suggestion... Edit/PS: to give some context to what I'm trying to achieve: getting the Link the "21st" i.e. Last page in this case, (the number of the last page will vary it won't always be #21)

Fair question... How about to capture the state of a "control" that cannot be accessed with something like WinGetText I suppose IUIAutomation may be the direction to go... Edit: better example of use maybe: Capturing Internet Explorer's rendering of a web page to an image file in the background

Agreed. And ScreenCapture is great as it is, top of the hat and all. Though then maybe there exists a different/better function someone has created for capturing windows without showing them to the user? One workaround that came to mind with ScreenCapture: WinSetState($hWnd, "", @SW_SHOW) _ScreenCapture_CaptureWnd(@ScriptDir & "\OK.jpg", $hWnd) WinSetState($hWnd, "", @SW_HIDE)Which then just briefly has the Window appear.

I tried this #include <ScreenCapture.au3> Local $iPID = Run("notepad.exe", "", @SW_HIDE) Local $hWnd = WinGetHandleFromPID($iPID) If IsHWnd($hWnd) Then _ScreenCapture_CaptureWnd(@ScriptDir & "\OK.jpg", $hWnd) ShellExecute(@ScriptDir & "\OK.jpg") ConsoleWrite("Success" & @CR) Else ConsoleWrite("Error" & @CR) EndIf ProcessClose($iPID) Exit Func WinGetHandleFromPID($iSearchPID, $tolerance = 2000) Sleep($tolerance); give the Window a chance to load Local $aList = WinList() For $i = 1 To $aList[0][0] If WinGetProcess($aList[$i][1]) = $iSearchPID Then Return $aList[$i][1] Next Return SetError(1, 0, False) EndFunc ;==>WinGetHandleFromPIDIt works fine without the @SW_HIDE, saves a screenshot of the Notepad window. with the @SW_HIDE, it just saves a screenshot of the area of the desktop where Notepad window would be I looked inside the <ScreenCapture> Include, and it looks to me like _ScreenCapture_CaptureWnd isn't designed for non-visible windows. It basically just gets the location and size of the window, and then calls _ScreenCapture_Capture to capture an image of that area of the screen.

maybe, in Edit mode, you're running it as a x32 program, and when you're running it in compiled form, as a x64 program (or vice versa)? I learnt (after many long hours) that putting this line in the top gives control over this. #AutoIt3Wrapper_UseX64=y ; Set to Y or N depending!Maybe this helps?

Func StartFishing();Keep checking for the fish until we find it, never give up Do Sleep(100) Until checkForTheFish() = True EndFunc ;==>StartFishingSeems you need to catch up on some basics. Start with some really simple scripts and examples from the helpfile like everybody did. Most days most people on the forums won't help you very much if you seem like you haven't properly tried doing your homework. Good luck! (oh, and take a look at my ImageSearch15.au3 version of the UDF that I uploaded one post before yours, I added _ImageSearchStartup() and _ImageSearchShutdown() functions, so that the Dll is opened once and not every time, which can make a script much faster. And I "fixed" some things I thought would make it more stable and reliable)

Depends what you intend to achieve. Maybe something in this direction? #include <ImageSearch.au3> HotKeySet("s", "StartFishing") HotKeySet("c", "close") Global $y = 0, $x = 0 While 1 Sleep(200) WEnd Func StartFishing();Keep checking for the fish until we find it, give up after 5 seconds if not yet found Local $timer = TimerInit() While Not checkForTheFish() And TimerDiff($timer) < (5 * 1000) Sleep(100) WEnd EndFunc ;==>StartFishing Func checkForTheFish() Local $search = _ImageSearch('fish.bmp', 0, $x, $y, 0) If $search = 1 Then MouseMove($x, $y, 10) Return True;Found the fish! Else Return False;Didn't find the fish yet... EndIf EndFunc ;==>checkForTheFish Func close() Exit EndFunc ;==>close

Something like this would have helped me so much:Hope it gives others a leg up!

I just got it to work! I was having much trouble, reading all the threads and posts related to ImageSearch, and I'd like to help others now. Now got it to work as a x64 and also as a x32 script using both DLLs accordingly (on a Windows 8.1 x64 PC) One of the steps I took in debugging was putting this into (the top of) my script: $sOSArch = @OSArch ;Check if running on x64 or x32 Windows ;@OSArch Returns one of the following: "X86", "IA64", "X64" - this is the architecture type of the currently running operating system. ConsoleWrite("$sOSArch=" & $sOSArch & @CR) $sAutoItX64 = @AutoItX64 ;Check if using x64 AutoIt ;@AutoItX64 Returns 1 if the script is running under the native x64 version of AutoIt. ConsoleWrite("$sAutoItX64=" & $sAutoItX64 & @CR)In any case you want to be consistent about 32bit or 64bit usage, and use the right DLL etc. What also really helped was putting in lots of debugging and error handling to zoom in on whatever specific part isn't working and why. Credits to Centrally (very helpful usage explanation and re-uploading the files) and kangkeng for making this possible in AutoIt, as well Miguel7 from the AutoHotKey forum who also posted some helpful advice. I've attached a zipped folder containing all of the needed Dlls and my customised Library, which also contains an example and some debugging: ImageSearch2015.zip Take a look inside ImageSearch2015.au3 here if you like: Edit: also uploaded "ImageSearch15.au3", a version of "my" ImageSearch Library without the built-in Example and Debugging (will require the Dlls in the .zip file though): ImageSearch15.au3 I hope this helps somebody! Let me know any feedback/issues.

Thanks for the replies, and I´ll take a closer (to be honest pretty much first) look at the Scite4AutoIt3 Helpfile in the near future, I promise. I´ll try it out.