Leaderboard

Thx, I'm always making Random mistakes like that.

So I think this is the easiest implementation of autoit image search ever, just grab the .au3 file and include it like in the example below, have fun. Thank you @junkew The original non-gutted and more powerful program can be found at the link below. ;ImageSearchExample #include <ImageSearchEasy.au3> Local $coordinates = SearchForClick("example.BMP") ConsoleWrite(@CRLF & $coordinates) Explanation: So due to a Java issue that I was having and searching around for a solution.. I found a super easy to use little script that requires no outside DLL's and works pretty darn well, so I basically gutted it and make it so anyone, even an idiot like me could use it. The part about this that really was great is that it works with any image search requirement as long as you can take a screen shot of it. 100% of the credit for this going to @junkew and the original link can be found at: EasyImageSearch.zip

Is it because english is not your favorite matter ? minute or two ?

The file that would be run is autoit3.exe, which is an .exe, it would just have a command line argument of yourprog.au3. You would put any necessary #includes in the same folder as where your Function.au3 was going to be placed, and path out to them in yourprog.au3. Not only that, you don’t even need AutoIt.exe, you can use yourprog.exe as the interpreter of yourprog.au3, since every .au3 compiled with the #pragma compile(AutoItExecuteAllowed, True) is a mini-interpreter. See here for the syntax needed to call it. So to recap, with this method, your function.au3 will not be “cooked into” the .exe, but rather the .exe will act as an interpreter of ALL your .au3 (if you choose not to use autoit3.exe directly). The upside is you will be able to change any .au3 on the fly without recompilation. The downside is you will need yourprog.au3 and any other UDFs to be local on the machine. Questions?

As far as I can see (I did not test your script), there is no obvious flaw in your code. However, I do not see the advantage of using events (but there is not harm doing so). Normal usage of events is to launch an overlapped function, and while that function is working you are free to do something else. When the overlapped function is completed, it is signaled as an event and you can react to it. Currently your code set manually events, because you are not using overlapped functions. You could do the same with global variables. But like I said, there is no harm doing it that way.

Can you post an image of a few of the automatic software setups screen you want to script along with the explanation of how pixelSearch can help you. For each image, please, show what au3info.exe tool says about the controls. FYI. Most installers offer silent install, you should look at this option instead of trying to make a standard install.

(Just a typo) - you surely mean : While Random(0, 1, 1) @Dxnny : It is already very late here in Germany, so I may have misinterpreted your question 😴. In principle, While...Loops can be nested : Global $vLoop1 = 1, $vLoop2 = 1, $i = 0 While $vLoop2 <= 3 ConsoleWrite(" --------------------------------------------- " & @CRLF) While $vLoop1 <= 5 $i += 1 ConsoleWrite("value i = " & StringFormat("%3i", $i) & " outer Loop = " & $vLoop2 & " inner Loop = " & $vLoop1 & @CRLF) $vLoop1 += 1 WEnd $vLoop2 += 1 $vLoop1 = 1 WEnd Also take a look at nested-loop

You can convert a whole file (single ASCII string) like this : #include <Constants.au3> Local $sASCII = "" For $i = 0x70 To 0x90 ; for an example instead of reading an ASCII file $sASCII &= Chr($i) Next Local $dUTF8 = StringToBinary($sASCII, 4) ConsoleWrite ($dUTF8 & @CRLF) Local $sUTF8 = BinaryToString($dUTF8, 4) MsgBox ($MB_SYSTEMMODAL, "Converted", $sUTF8)

With a couple more hours of effort, I now have a workaround. First, I've concluded that there's some deep-seated problem with the way MDI Child Windows are managed when they're deleted. I was using the MDI child method for a small overlay panel that my GUI uses. It worked well because it would overlay whatever was defined under it on the main GUI (... which happen to be Flat Buttons). As I stated, previously, the problem was that when I was finished with the overlay panel and deleted it, the Flat Buttons were deleted upon the first drag action of the Main GUI. My workaround is this: before creating my overlay panel, I use GuiFlatButton_SetState to hide the buttons that are under the panel. I then create the panel as a simple Child window (not an MDI Child). I then delete the panel and $GUI_SHOW the hidden buttons. Everything now works fine. Unless someone poses at clean solution, I'll use this method and consider the problem solved. (And, BTW, searches on this forum revealed there are enough fringe problems with MDI Child Windows to give one doubts about using them in any situation beyond the simplest ones.)

After much testing, I can add a couple more findings: OnAutoItExitRegister("GUIFlatButton_Exit") does not appear to be a problem. I removed it and added the delete button call to my _Exit() and the buttons still disappear. But I have now isolated a main suspect. One of the functions of my GUI creates and then deletes a $WS_POPUP overlay window that is defined as an MDI_CHILD window. After that function has been used, the flat buttons always disappear the next time I try to drag the main GUI to a new position on the desktop. Without the drag GUI action, the flat buttons are fine and work properly. But any subsequent drag causes the buttons to immediately disappear. This is about as strange as anything I've ever encountered with Au3. I'm trying different combinations of CLIP_CHILDREN and CLIPSIBLINGS, but so far, nothing helps.