lgodfrey

Sorry, should have been more specific, I have not been able to find an Opt() setting that helps with the slow AutoITX time compared to the faster AutoIT time. Setting SendWaitDelay to 1 msec did help both a little (about 20% so the time is just under 20 msec for VBA now for the Send method, no change for the WinGetText). I did find a reference that said "early binding can improve performance". The examples were aimed at binding office objects, not general objects, so I am over my head on this concept. Here is how I implement AutoITX in vba as an example (this I think is late binding). Public oAIX As Object Set oAIX = CreateObject("AutoITX3.Control") bSuccess=oAIX.Send("^A") From this new reference, this "late binds" AutoITX to the code, ie it only does the binding when the createobject code line is executed, not when the code is compiled. It looks like to early bind, you have to be more specific on the declaration of the object. With the extra info, I guess the binding can take place at time of compiling. Here is an example given: Public xlApp As Excel.Application Set xlApp = CreateObject("Excel.Application") My guess is that the equivalent version of AutoITX is: Public oAIX As AutoITX3.Control Set oAIX = CreateObject("AutoITX3.Control") This gives a compile error on the public dim statement that "User-defined type not defined". So, .... do you think early binding will help with the speed disparity? Any idea how to do it in VBA (Am I at least on the right track so I should spend some time on a VBA forum to find out more?)

Thanks for the feedback, MHZ. I have done some more timing testing, and the two items that seem to be quite long are the WinGetText and the Send methods. Control specific methods like ControlGetText and ControlSend work about 10X faster. Since I have several WinGetText/Send's in my current code which take up far too much time, my workaround is now to never use these unless absolutely necessary. If I can't use control methods, then I have set up a AutoIT program that performs the send and get at 3X the speed of the same code in VBA, and then put the info into a splash window. VBA uses a control method to get the info from the splash window rather than using a WinGetText to get the info from the window directly. THis is ugly, but much faster. You have to be carefull about the asynchronous aspects of this info transfer. It also has the advantage of working on different threads, so it gets a speed boost if used in multi-core/processor machines. However, I am still hoping there is a more elegant way of reducing the over-head inside the VBA code that someone might be able to tell me about. I haven't been able to find a Opt() setting that helps.

If one runs a typical AutoItX function from within code such a Excel VBA, such as WinGetText, it takes about twice as long as the same function call from code being run from Scite, and almost 3 times slower if run from the compiled versson of the script. The latter I can understand (ie the compiled version running faster than from within Scite), and the fact that there is more overhead running inside VBA I can understand. But a 2X time hit seems excesive (25 msec vs 12 msec for the WinGetTxt on my 3Ghz P4.) The WinWaitDelay setting is at its default value of 250 msec, so it would not appear to have anything to do with this time difference. I am fishing for ways to cut down on the time overhead withing VBA. Is there a way to "keep the connection live" between AutoITX and VBA so that AutoITX is always "ready" for the call from VBA?(this is a pure guess question on my part, ie I am guessing VBA needs to "re-open an AUtoITX channel" for every call to AutoITX). Sorry I do not know the right technotalk for this concept. Does a multi-processor machine handle this time issue better than a single core processor? Any suggestions how to reduce this time significantly? Best regards, Larry

Followup: I've tried to run some tests again to look at these questions, and the only thing I have found so far is that: If a dialog window is open in the main coding, it appears that execution control will not be given to the function associated with the GUI event until that dialog window is closed. Of the questions I asked, the one about recursive calls to functions is the most important to me.[' Best Regards Larry

I thought I's check to see if there was anything I can do about this instead of assuming I am up a creek. I know this is a pretty standard problem, but haven't been able to locate a workaround that works on this window. I have a program running that displays text messages in a normal looking window. I can see the text, but Window Info tool does not, and WinGetText does not. (neither visible nor hidden text) It looks like this is not a standard window. Is there any method that I can look at to capture this non-standard text? By the way, the text cannot be selected with the mouse, nor does it get copied with Control-C, two options I did find while looking for a solution on the forum. Regards Larry

I do not know how to test this to get the answers, so I thought I'd ask so I make sure I know exactly how code execution is controlled using GUIs. I am running GUI in event mode. 1) when an event interrupts the main code, is this interruption done at the term level or the line level? eg the main routine is executing the line IF a>b or c>d then dosomething() I can see four possible interuption points in this example: The term a>b is being evaluating when there is a GUI event notification reaching the main routing. Is this term calculation interrupted, or is the term calculation finished and the the line interrupted before the c<d term, or is the full logic statement calculated and then the line interupted at the branch point "then", or is the entire line finished and then the code is interrupted before the branch to the function dosomething? 2) When the function assigned to the button is being executed, is code execution control maintained by the code flow of the assigned function, even if the assigned function calls other functions? Maybe put another way: regardless of function calls withing the assigned function, the main code is interrupted until the assigned function sees an endfunc or a return? 3) Can the assigned function for a GUI button recursively call another function that is in the middle of executing code since it was called by the main code? IE Function1 has been called by the main routing and is executing line 10 when an event interrupt triggers Funciton2 Func Function1() 1... 2.. . . 10 main routine is executing this code line when event triggers Function2 . . Return $answer EndFunc Func Function2() 1 2 3 $X=Function1() . . EndFunc Does the current execution of Function1 halt, and then all the code of Function2 executed, including Function1, and then control is returned to the main code and picks up at line 10 of Function1?

That did the trick! Thanks as always for the great support on this forum.

My apologies before hand if this is the wrong place to post this question, or if the answer has been given before (even though I have searched off and on for the answer over the past several years) Is there a way to have multiple windows withing one instance of SciTE or multiple instances of SciTE to make it easier to look at parts of scripts separated by many "page down"s of code lines? (This is very usefully if building code based on some building blocks from another script that you do not want to make UDF's of) Best Regards Larry

Red and green are in decimal. I have used debug to console to make sure. My initialization of the red and green values match the returned color value when it does find red or green. Don't know if this makes any difference, the pixel color is set by other "script" to these pre-determined shades of red and green, so the colors should always be exactly these shades. Sigh, Next what should I look at?

I am looking at a column of around 120 pixels to find the color. The colors are either red or green as verified using Window Info Here is the code: CODEFunc R1Color() For $y = 560 To 683 Step 3 $C = PixelGetColor($ColorR1X, $y) If $C = $Red Or $C = $Green Then Return $C EndIf Next ToolTip("Can't Find good R1 color") Return 0 EndFunc ;==>R1Color If I set the image so the colors do not get updated, I get the correct color returned. I can move the image I am looking at so either red or green color is in the search area. This seems to work. However, if I allow the image to get updated frequently (ranging from 100 msec to 1.5 sec between updates), it no longer returns the color I see on the screen. It returns 0 or even the wrong color. Turning off virs scanand firewall doesn't help. Anyone have any suggetions as to what to look at?

a-ha, it had to be somewhere! did not look at edit list before :"> edit but the number pad - key is my favorite, not in the edit list

downloaded, and works for me! Thanks!

Thanks! I do not feel so bad now....these are not listed in Scite help file under keyboard commands I guess they are not listed in general help section 'cause they are specific to AutoIt3. Can't find them in Scite/AutoIT3 specific files. I'm off to the races!

I'm sorry, but after a year of no scripting for the life of me I can't find this anywhere... how do you, in scite, use a key input to comment out a line of code and toggle it back from a comment to a code line? (it automatically puts comment character at beginning of line, or removes it) I am sure I could do this before for debugging purposes, but searches in forum and scite help files came up with zip. Larry

I just uninstalled older AutoIt and Scite files, and downloaded the newest versions following instrucitons referenced in JdeB ' signature list http://www.autoitscript.com/autoit3/scite/...nstallation.htm When I tried to run it on a file NAME.AU3, Tidy kept asking for file name whether run from SCITE or as exe file, every time I selected the NAME.AU3 file, it just popped up to a new "open file window" when I renamed the file NAME.au3, Tidy ran from Scite and from the stand alone open file window. Scite doesn't seem to care about the case of the file extension. Do I have a setting wrong, or is this behavior to be expected and/or desired? Regards Larry