Duel Monitor Pixelcolorsearch Problem

[Bert]

This one is a strange problem. I'm not sure if this qualifies as a bug, but it is very odd. I run a duel monitor setup on my work PC. I have this line of code:

$colorwin = PixelSearch($xm1, 400, $xm1 + 30, 416, 14079694, 10)

If I change it to this:

$colorwin = PixelSearch($xm1, 400, $xm1 + 30, 416, 14079694,3)

the script will only work in the right monitor. I have to change the shade variation to 10 if I run it in the left monitor, though I can leave it at 3 if I run it in the right monitor. I'm concerned for I wish to deploy this script to other users, and I do not wish to have this be a possible failure. Would this qualify as a bug?

[Bert]

I have a pixelgetcolor in another place to tell me where to search for the second pixel. Once I get the y from the first seach, I add 241 to it to get $xm1.

In testing, I put a msgbox to report where it finds the pixel, and it finds it in both monitors in the same spot. The problem seems to be the pixel is a different color on the different monitors. I'm going to do a test where I will do a pixelgetcolor and a msgbox to see what is being reported on each monitor. I will post when I get the results.

[Bert]

I figured out the problem. My monitor on the left is set to 32bit color. The one on the right is set to 16bit color due to the fact it is a old PCI card, and this is it's highest setting. Because of this, the pixel selected will have a different color code depending where it is being displayed. I'm thinking this possible problem should be mentioned in the help file. The wording should be something like this for PixelSearch:

Remarks: Depending on your color quality settings, you may experience a script error if your script is distributed to other computers. You can adjust the shade variation help compensate.

[SmOke_N]

I figured out the problem. My monitor on the left is set to 32bit color. The one on the right is set to 16bit color due to the fact it is a old PCI card, and this is it's highest setting. Because of this, the pixel selected will have a different color code depending where it is being displayed. I'm thinking this possible problem should be mentioned in the help file. The wording should be something like this for PixelSearch:

Remarks: Depending on your color quality settings, you may experience a script error if your script is distributed to other computers. You can adjust the shade variation help compensate.

? I would think it would stand to reason that if you are going to use the Pixel functions, that you understand that the colour output is going to be different in any change in bit quality? Just looking at your monitors showing the same picture would give that away ... no?

[Bert]

I forgot about the fact I had 2 different settings, and also it is something a coder can easily overlook. Kind of like the person who beats themself up with a problem, and it is something real stupid, like a cable being unplugged. This happends to everyone from time to time. To the person who says "This never happens to me" is only fooling themselfs. I've seen the best tech make the mistake and didn't check to see if something was plugged in.

I still think the remark I put in my last post should be added to the helpfile.

[SmOke_N]

I know your frustrated that was a simple overlook, but I don't think the "obvious" should be posted in the help file on every function, otherwise it would be 10x's bulkier. And I agree that everyone makes mistakes, my comment was not pointed at you, but at the fact that it was not the "scripts" fault, but the end-user/programmers for not checking their conditions correctly. AutoIt shouldn't be held responsible for that.

[Bert]

Agreed. I wonder if a better place to post this would be some type of troubleshooting FAQ. I know the forum is supposed to be for that, but unless you know just what you are looking for, you get buried in post trying to find what you want.

[CyberSlug]

A one-sentence addition to the remarks, in this case, would make sense to me.

[SmOke_N]

A one-sentence addition to the remarks, in this case, would make sense to me.

Of course it would, and now I look like a total ass... [rant]...[/rave]

[MHz]

Of course it would, and now I look like a total ass... [rant]...[/rave]

lol, well, I can tell the difference to say 4 bit colour(some 8 colours) to 32 bit(some 64,000 colours). Ofcourse pixel... will foul up.

[Bert]

Thats why I first wanted to have this added:

Remarks: Depending on your color quality settings, you may experience a script error if your script is distributed to other computers. You can adjust the shade variation help compensate.

Edited May 19, 2006 by vollyman

[MHz]

Remarks: Depending on your color quality settings, you may experience a script error if your script is distributed to other computers. You can adjust the shade variation help compensate.

Shade variation? Do you not mean the Bitrate of the display?

I would also advise that you could enter a warning into your script that would detect an incorrect display setting needed. As being a dev of your program, it lies upon you to look for unknown problems that may occur from the progams usage.

[SmOke_N]

Shade variation? Do you not mean the Bitrate of the display?

I would also advise that you could enter a warning into your script that would detect an incorrect display setting needed. As being a dev of your program, it lies upon you to look for unknown problems that may occur from the progams usage.

Hey, I even wrote one of those that checks it in the registry for just this reason (Hindsight?... I think so ), I don't know if it works "every time" but it checks the registry for the color settings.

Edit:

Found it, if you see/know a better way to do it, I'm all ears (eyes ).

Func ColorQualitySetting()
    For $i = 1 to 100
        $InitialKey = RegEnumKey("HKEY_CURRENT_CONFIG\System\CurrentControlSet\Control\VIDEO", $i)
        If @error <> 0 Then ExitLoop
        For $x = 1 To 100
            $NextKey = RegEnumKey("HKEY_CURRENT_CONFIG\System\CurrentControlSet\Control\VIDEO" & "\" & $InitialKey, $x)
            If @error <> 0 then ExitLoop
            For $y = 1 To 100
                $MonKey = RegEnumKey("HKEY_CURRENT_CONFIG\System\CurrentControlSet\Control\VIDEO" & "\" & $InitialKey & "\" & $NextKey, $y)
                If @error <> 0 then ExitLoop
                If StringInStr($MonKey, 'mon') Then
                    $ValueRead = RegRead("HKEY_CURRENT_CONFIG\System\CurrentControlSet\Control\VIDEO" & "\" & $InitialKey & "\" & $NextKey & "\" & $MonKey, "DefaultSettings.BitsPerPel")
                    Return $ValueRead
                EndIf
            Next
        Next
    Next
    Return 0
EndFunc

Edited May 19, 2006 by SmOke_N

[CyberSlug]

Found it, if you see/know a better way to do it, I'm all ears (eyes ).

I'd use the @DesktopDepth macro in the current beta

[SmOke_N]

I'd use the @DesktopDepth macro in the current beta

AutoIt Jedi to the rescue!!

I didn't even see that implimented!!

I had asked about this option several months ago, and had to go through all that to get what I wanted, 1 word, 1 line = instant results ***BAM*** !

[Bert]

Some users may have a video card that doesn't support the bitrate that your PC supports. That is the problem I have with one of my video cards. With hindsight being 20/20, I made the suggestion that the coder use the shade variation to compensate to allow for this. The coder does not have control of other computers when it comes to the bitrate being used on other PCs, and for that matter, knowing what hardware is being used.

You are correct in that the best approach is to put in error protection to notify or to look for unknown problems. My main point in the remark line is that it is a known gotcha for the inexperienced, and a friendly note would help. The experienced do not need to reference the help file as often, but to the newbe, they treat it like a tell-all of how to code with AutoIt. It doesn't hurt to help.

[MHz]

Some users may have a video card that doesn't support the bitrate that your PC supports. That is the problem I have with one of my video cards.

Correct me if wrong, but you have an old video card that does not have the "filters" to output what the other program code uses or a out of date driver issue. Then you have another problem. Now you have a problem that is differcult to comprehend to warn with code. I guess that you will not be able to warn against all problems as able to, but the bitrate would be a good one atleast to cover for.