Wait For Pixel Change

[HeyJim]

I'm having lots of trouble with wait for pixel to change color. 90% effective just isn't good enough.

 

It seems that the window is stable and consistent in terms of position on the screen but apparently it's, what? moving a pixel or two? To the human eye it looks like the window is always opening in exactly the same position on the screen.

 

About 10% of the time the macro acts like it doesn't wait for the pixel change and just rushes ahead and I lose some information. I guess because I'm brand new at this I'm even having trouble using a different pixel location. I've tried different pixel locations, screen position versus window postion, wait for "equals" and wait for "different then". Nothing much works.

 

Either the macro doesn't wait for my color change (when logically I don't see why it wouldn't) or it waits forever and I have to abort the macro. This is when I try to deviate from my current macro which is 90% accurate.

 

Anyone have any suggestions on how to whip a macro into shape that only works 90% of the time?

 

Currently I'm using (rough code):

Text type ENTER

Repeat until %n1% = 14215660

Get pixel: screen coords:423,379 into %N1%

Repeat end

Delay 1 second

Text type TAB

Text type ENTER, etc.

 

I insert the TAB which then brings the window into focus and the ENTER clicks the FINISH button so the software can move on which, coincidentally, is also where the macro loops back and I process the next line in the csv file.

 

The window title doesn't change, only the text in the window. The "print" is an image. Can't highlight it and copy it so can't focus on it.

The only thing I'm left with is to replace waiting for pixel change to left click mouse. I really don't want to do that but I'm not sure if I have any alternative.

 

Any input really appreciated.

[joe]

If you are waiting for a pixel to change into a particular color, and if it is inside a window, use the relative to window option instead of relative to screen. This way it does not matter if the window moves or not. Make sure that the window containing the pixel has focus.

 

A pixel coordinate is a pixel coordinate is a pixel coordinate. It is an exact location, so if you are sure that that is the correct coordinate, then everything should be fine. Once that pixel changes to the expected color, the loop will exit. Are you sure of the color that you are waiting for? Is it always the same color? If not, you will loop forever.

 

Put a 10ms delay in the loop. Give the macro time to breathe.

 

Without seeing the actual code, these are the only suggestions I can make.

[Nicolas]

I don't see anything really wrong in this code ... not really ... maybe you could try that :

 

Text type ENTER

variable set integer %N1% to 0 /* to be sure it won't go out of your loop at the second call */

Repeat until %n1% = 14215660

Get pixel: screen coords:423,379 into %N1%

Delay 1 second /* it sometimes help to have the CPU slow down */

Repeat end

Delay 1 second

Text type TAB

Text type ENTER, etc.

 

 

and to be sure your window is always positionned at the same coordinates, do it yourself :

 

Activate Window: "xxxxxxxxx"

Window Reposition: Current Win - (Left: 0, Top: 0)

Window Resize: Current Win - (Width: 1000, Height: 720)

 

last thing : if you're using your macro on two different PCs, colors can have different values ...

[kevin]

I don't know if you are using Windows XP with Windows XP Themes but if you are ...

 

I had trouble with some macros I was writing for Windows XP. The macro was using the Get Pixel Color command to determine the status of several checkboxes. I determined what color I wanted the macro to watch for (green) but it would not work in every checkbox.

 

It turns out that the Windows XP themes use gradient colors and shading in many of the areas on the screen. The color looked to me like it was green but there were many different shades of green. And, some of the boxes that I thought were white actually contain different shades of white. I discovered what was happening by capturing the image from the screen and examining it in a paint/photo program.

 

To fix my macros I had to adjust all of the pixel locations by hand. I could not rely on the Mouse Locator to position to the exact location.

[HeyJim]

Thanks everyone. This gives me something solid to look forward to trying when I get back to the office Tuesday. I"ll let you know how this turns out.

[HeyJim]

Nope. Tried everything except setting the pixel manually. Not sure how to do that without using the mouse locater.

 

It's not like the concept is difficult to grasp. The only part of the active window that changes color consistently is the CANCEL button which changes to close at one point. When it changes to CLOSE the pixel changes to the color that the macro is waiting for. Sometimes it works. Sometimes it doesn't. That button location does have a border that changes color when I mouse over it but not until it changes to CLOSE. I'm sure that has something to do with my problem but I have to get productive now.

 

Wait for mouse click here I come.

 

Thanks though.

[kevin]

That button location does have a border that changes color when I mouse over it

This might provide a clue.

 

Windows XP changes the color of a button when the mouse pointer is moved over it. This makes it so you cannot use the Mouse Locator to determine the pixel color.

 

This may also explain why it works 90% of the time and fails sometimes. Could it be that when it works your mouse is not over the button (or visa versa)?

 

To get around this, use the Mouse Locator to determine the pixel that you want and write a macro to get and display the pixel color in a Text Box. Run the macro with the mouse pointer over the button and again when the mouse pointer is not on top of the button. Do this when the button says 'Cancel' and again when it says 'Close'. This will result in as many as 4 different pixel colors (2 for Cancel and 2 for Close).

 

Then write your macro using two If Variable statements separated by an OR:

If Variable %N1% = 000000
 OR
If Variable %N1% = 210005
 // The button says Cancel
End If


If Variable %N1% = 16777215
 OR
If Variable %N1% = 16776958
 // The button says Close
End If

 

But, have you tried to use the Window Controls commands to determine whether the button says Cancel or Close? If the button IS a Window Control you can use something like this:

Get Control %C1% (ISS Issue Tracker: Button)
Variable Get Control Text: %C1% to %T1%
If Variable %T1% = "Cancel"
 //   The button says Cancel
End If
If Variable %T1% = "Close"
 //   The button says Close
End If

[HeyJim]

I think the solution to my problem is using the window control for a button although for the life of me I can't understand why a pixel changing to the color I need won't work.

 

Anyway, too new to this to know or remember about window controls and buttons I figured this had to be the answer. Having 15 minutes before I had to leave for an appointment I jumped on the macro to give this new option a try.

 

The first couple of times it didn't work at all. I played around with the macro a bit and got closer to a solution when the macro aborted because it couldn't find C1. (I'm going on memory here.)

 

On the way to my appointment it occured to me what is going on now. (I think).

 

Lets say the software goes through four processing windows: A, B, C and D. I've been waiting for a color change in D to hit enter. I used the same thinking to grab the button for window D that says CLOSE but what I really need is to patiently loop during window C and then when that button disappears break out of the loop and move on with the macro since the CANCEL button in window C moves elsewhere (changes name?) in window D.

 

So when I go into work tomorrow I'll be checking to see if the macro will continute to loop while the CANCEL button is present and then break out of the loop when the window changes to D and the CANCEL button no longer exists. I also wonder if although the next button (CLOSE) is in a totally different place and in window D, if it's actually the same window control and I can just focus on the button text changing from CANCEL to CLOSE.

 

As always, any input greatly appreciated.

[HeyJim]

No. I have the entire macro working fine, processing a csv file, etc. Thought that was pretty good that this software would enable a rank amateur to put this all together. I just can't get anything to pause the macro effectively except waiting for a mouse click.

 

Thanks for trying people.

[HeyJim]

Had another thought on how to make this work.

My original script was 90% effective. What can I add to the processing loop so that when each line in the csv file is processed it is erased? The ten percent of lines that were skipped the first time through could then be processed on a second go through or maybe the macro just keeps repeating until every line has been processed.

 

It certainly seems as though that should work. At least I'm very hopeful again.

 

{I guess I shouldn't post too early in the morning. I just realized that every line really is processed, it's just that some lines are accessed by the macro while the software is doing other things and so they're just lost then from the process.

 

Back to the drawing board.}

[HeyJim]

I think I finally have it.

Since the original macro configuration worked 90% of the time, to state the obvious, 90% of the time it WAS waiting for the correct pixel to change to a new color. It was the other 10% that was puzzleing.

 

What I did was create two more pixel change loops, all right after the other to catch most if not all of the odd 10% that was slipping through. A couple of short trial runs indicate that it's working! I'll keep my fingers crossed for later but logically I think I have to have it running at at least 99% accuracy and I can live with that, I guess.

[KFOR777]

Just a Reminder!

 

When using pixel color as a loop... if you happen to change your color scheme or if you have others use the macro and they change the color scheme...

 

The macro will cease to work.

 

I know from expeirence.

 

Keith

[HeyJim]

Gotcha. And, thanks. I'll be upgrading to an LCD monitor soon and I know I'll have to make a couple of changes at that point.

 

For those searching the board for pixel change solutions, the triple loop to catch odd pass throughs did work.

[joe]

HeyJim -

 

I can guarantee that, in the following code segment, the loop will exit every time the pixel color at coordinate 100,100 changes to white. This happens 100% of the time. Period. It is an absolute.

Repeat Until %N1% = 16777215

  Get Pixel: Window Coords: 100,100 into %N1%

  Delay 10 Milliseconds

Repeat End

There are only two events that can occur which would prevent this loop from exiting:

1. The window containing the pixel does not have focus
    
   
2. The pixel, when it changes, does not change to white.
   

In your case:

Lets say the software goes through four processing windows: A, B, C and D. I've been waiting for a color change in D to hit enter. I used the same thinking to grab the button for window D that says CLOSE but what I really need is to patiently loop during window C and then when that button disappears break out of the loop and move on with the macro since the CANCEL button in window C moves elsewhere (changes name?) in window D.

Since you are processing through windows are you using the relative to window option instead of relative to screen? The macro may be waiting for the wrong color at the wrong coordinate in the wrong window 10% of the time depending on what is on your display at a particular instant and how the target program is running. You say that putting in extra loops works better. That makes me think that there is a timing issue between what the target program is presenting and what the macro thinks should be occurring.

[paul]

Having done some complex work with pixel detection, I have observed that upgrading a video driver (or, even worse, changing the video controller) can result in different colours, and different pixel locations. For example, I wrote a complex script to detect a particular tray icon, both in terms of its size and the pixels being used. When I updated my video driver, the icon sizes all changed from 22 x 22 to 24 x 24! And colours were different - what was previously, say, 12345678 was now 12345679! Of course, the new command "Move Mouse to Tray icon" makes all my code entirely redundant.

[HeyJim]

Joe, I put two of your comments to use and seem to have corrected the problem. Thanks!

 

I believe the fundamental timing issue was that the window was coming in to focus too slowly at times. I enabled a 3 second delay prior to the loop and disabled the two redundant loops and it seems to be working fine.

 

I did have the 3 second delay in already that I was trying at one point but I guess there was a error in my pixel detection commands when the delay was enabled and that led me astray from the solution. The delay "didn't work" at that time so I went looking elsewhere for a solution and eliminated the delay from the macro.

[dweebflarg]

I've been trying to get just a pixel color detection to work to wait for a change in a window.

 

Repeat Until %N1% = 14215660

Delay 5117 Milliseconds

Get Pixel: Window Coords: 1434,113 into %N1%

Text Box Display: Pixel color

Repeat End

Text Box Display: Done

 

I originally set this up using the mouse locator to get the window coordinates and the color integer. It never detected the color.

 

Then I added the text display to show me the color it was detecting. It wasn't the same as what the mouse locator had shown me.

 

So I changed the integer in the Repeat Until to match the color actually detected. Then it seemed to work, but it also falsely detects the color when that part of the window is an entirely different color.

 

I think the Get Pixel and the mouse locator use different coordinates, and the Repeat Until is broken.