Strange result with PixelChecksum

[Sonolin]

I am creating a bot program with Python using AutoIt and things have been going very smoothly so far. However, something strange always seems to come up whenever I use the PixelChecksum function. If I use this function in an .au3 script (straight AutoIt), then everything works completely fine. However, if I use it in Python it returns the following value:

-2147483648

Which is very strange, since I do not think checksum should ever return a negative anyway, not to mention the large and odd number returned. Some instances work fine, but most others do not (which also adds to the strangeness..).

If further interested, here is some extra info that may help you:

I am creating a MTGO smart bot. I doubt anybody here would want to go through the trouble of installing MTGO (unless they are already players hehe), but if so, I resize the window to exactly 1280x768 via click dragging. Position set to 0, 0. Some instances of this strange number being presented: on the collection screen (click the details view) if I get a checksum of card names, in trade if I get a checksum of the card quantity. Some instances of it working correctly: getting a pixel sum of the PM text. Again, I doubt this would help my case much as I'm not sure of anybody who uses MTGO here, but this info is worth a shot.

A simple code example... requires win32com package for python, I use python 2.4:

import win32com.client

auto = win32com.client.Dispatch('AutoItX3.Control')
# The following is an example of getting the card quantity in trade.
print auto.PixelChecksum(69, 580, 82, 585) # should print -2147483648 if window correctly resized

Again, works fine in an au3 script. Strange.

Let me know of any possible solutions at all, or anything else that would help debug the problem. Currently, I simply use a custom checksum routine I created that basically gets a sum of every PixelGetColor in the box, but is very very much slower (to speed it up I have a skip argument that can be supplied to skip a certain amount of pixels each loop iteration). Any ideas on how to make this speedier and more accurate (I don't want to have to make a 500 line algorithm for not such an important feature, but any simple suggestions are very welcome).

Regards,

Michael

[Richard Robertson]

That number is actually not all that uncommon a number. That is the minimum negative value of a 32 bit signed integer.

It could indicate an error of some sort.