|
Post by niteowl on Dec 15, 2018 21:46:49 GMT
I am trying to detect when a pixel changes color then go to the next line but nothing happens when that pixel changes color. If I change to a different window it immediately evaluates true and continues but not if I am on the same screen.
This is as simple as I can make it for testing, perhaps I do not understand the condition. Does the below only check a single time until something other than a change on the same screen occurs? The color and x/y coordinates were entered with the wizard, not by hand so they should be good. Or can Windows 10 scaling settings throw off the coordinates?
1 | IF | PIXEL COLOR | Color [R=255, G=255, B=255]::At Location [X:775 Y:145] | IS NOT THE SAME | CONTINUE
2 | 376 | 153 | 100 | Left Click Down
3 | 376 | 153 | 10 | Left Click Release
|
|
|
Post by Johnc on Dec 16, 2018 1:04:08 GMT
Looks like your initial color at this specific location is pure white 255,255,255 and then u r looking for it to change to any other colors. This pixel color condition will wait indefinitely until the color change occurs and then it will execute the continue action to go on to the next line. Think of the continue statement as "wait 1ms".
Not sure what went wrong with your codes but u can try the following:
48 | IF | PIXEL COLOR | At Location [X:316 Y:943] | CHANGES::1::0::0 | CONTINUE
This will always detect a single color change at this specific location regardless of what the initial color was.
|
|
|
Post by niteowl on Dec 16, 2018 3:27:00 GMT
Thanks for the reply. Unfortunately still not working. It may be the x/y coordinates not being correct. This is a flash app on a web page with a progress indicator. When it reaches a certain point I want to trigger the commands. I used the built in selector to get the coordinates but it still fails to trigger when the indicator lights up that area. If I scroll the page at all it triggers. If I change to a different screen it triggers so it does pick up a color change, just not where I need it to. So maybe the coordinates are somehow off.
Is there any way to read the rgb values and pop up a message with them so that I can see the value before and after a change? My laptop runs at 1920x1080 which makes things kind of small on this 15" screen so I set the Scale and Layout setting in Win 10 to 150%. I wonder if something in how Windows scales things throws off correctly detecting the coordinates.
|
|
|
Post by Johnc on Dec 16, 2018 4:13:55 GMT
The windows scaling to 150% might be a problem. Steve will have to answer that. But the x,y coordinate display at the lower right corner of the MMM window should be accurate. Another way to test if the coordinate is right is that u can "mouse over" that point to see if u get any response. If no, then u know u have a problem! U might also want to take a look at the new "pixel range" condition which can cover a much wider area, if that helps. BTW, u have to modify the x,y in my example to your own need. It was just an example.
|
|
|
Post by niteowl on Dec 16, 2018 6:17:19 GMT
I had verified with the x/y coordinates from the main MM window, it shows the same as the selection tool. It makes no obvious sense. I was hoping there was just something about how the commands worked that I did not understand. I had updated the coords in your example. The effect is the same. The color in that area changes without triggering the condition but if I scroll the screen at all it jumps to the next macro line. Changing to a different browser tab triggers it just the same way as you would expect, just not a color change on the screen where expected.
|
|
|
Post by niteowl on Dec 16, 2018 22:03:27 GMT
Oh, I forgot to mention. Mousing over the area does not trigger the condition either. I moused over half the screen trying to see if it was picking up the pixel in a different location. I assumed that the mouse pointer was treated differently than the main screen and would not be included. That seems to be the case here but I would like to know if it is a factor under other conditions.
|
|
|
Post by Steve on Dec 16, 2018 22:30:41 GMT
Hi niteowl, Windows scaling does not change the resolution, it just makes things scale larger or smaller changing the size of things like icons. As long as you record the macro after you set your scaling then the pixels should match whats on the screen. I think I know what the issue is. As soon as you said that the target is inside a flash window then it started to all make sense. Basically, sometimes windows with flash, java, or other embedded content run in an isolated fashion from the main desktop. Sometimes these windows prevent the system from writing in and out. For example in some flash games the flash window may only active when you click into the window. When these windows behave like this they essentially 'cut off' MMM from interacting with them. I've got a deeper explanation in this thread here if you want to dive into it. Bottom line is that the pixel condition may not be able to detect the color change from inside the embedded flash content. Hope this helps.
|
|
|
Post by niteowl on Dec 17, 2018 22:14:30 GMT
I thought it would be something related to how Flash works but when I thought about it that just did not seem right. The chooser has no problem detecting the current pixel color when I set it up to begin with so the only reason I could think of why it would fail with the script running is if the Flash app somehow loses focus. I tried adding a click nearby on the screen to make sure it at least initially has focus but no luck. So I changed Windows 10 Display settings Scale & Layout to 100% (down from 150), selected a new location with the chooser and it worked.
I have tested with Chrome set to different magnifications and as long as Windows Scale & Layout is at 100% it works. Windows 10 defaults to 125% so I would expect more people to have problems but who knows what other variables might play into it. I have not yet tested at 125%.
|
|
|
Post by Steve on Dec 18, 2018 0:19:38 GMT
Ok well thats a good outcome. I wouldn't have guessed that the scaling would effect it. As long as your X and Y coords match for the pixel original location then i figure it would work. Nice one.
|
|
|
Post by niteowl on Dec 19, 2018 17:42:10 GMT
I would not have thought it would work that way either but Windows is doing something in the background to try and improve clarity of the text in applications when scaling is applied so who knows what the effect might be in any given application. It could be that text in a higher portion of the screen is enlarged causing the section of the page it is in to enlarge pushing other items further down or to the side. I w%ould expect that by the point I am selecting a pixel from the chooser that any screen adjustments have already been made and it should work but it does not.
I have done experiments with how focus is applied to the area of the page I am checking both before choosing the pixel and during run of the macro but the only thing that has made a difference is setting scaling to 100%. This might not be an issue for most people but on my 15" screen the text at 1920x1080 is too small for me to read.
I will have to experiment more and see if I can identify coordinates that work without being at 100% scaling and compare against what the chooser shows the area as. This could be difficult to track down and of dubious value to anyone else given differences in screen resolution and scaling combinations that might make any type of calculation extremely difficult to come up with.
I have seen similar issues with another macro automation tool which is what made me think to look at the scaling setting but there is no explanation to the problem there either.
I always run into the odd stuff.
Thanks for the replies. I will post anything useful I find.
|
|