It should be throwing an exception or returning null, returning a real value is 
a code smell.

Sent from my iPhone

> On 23 Mar 2014, at 07:55, Daniel Blaukopf <> wrote:
> We should be consistent about what we return, although I agree that that the 
> actual value doesn’t seem to matter. 0 for imaginary pixels seems reasonable.
>> On Mar 21, 2014, at 7:05 PM, Anthony Petrov <> 
>> wrote:
>> Hi David,
>> I don't think we're making any assumptions. We feed the coordinates to a 
>> native API and rely on the OS to do the right thing.
>> In other words, our assumption is that if the box lays (partially or fully) 
>> outside of the screen area, then the behavior is undefined. Note that the 
>> Screen API in Glass allows its clients to check what coordinates are valid 
>> (i.e. belong to a real screen).
>> So whatever your return for pixels outside of screen bounds should be fine. 
>> 0x0 or 0xff000000 - both look good. However, I agree that a stricter 
>> specification and a check might be the best solution.
>> --
>> best regards,
>> Anthony
>>> On 3/21/2014 8:53 PM, David Hill wrote:
>>> I have been working on a problem with Robot.getScreenCapture() on a 565
>>> ARM device, and while doing so, encountered a couple of questions which
>>> I will bring up:
>>> Pixxls getScreenCapture(int x, int y, int width, int height, boolean
>>> isHiDPI)
>>> I don't seem any real documentation that says how x,y + width,height
>>> should be treated when compared to the reality of the Screen.
>>> What values of x,y + width,height  are reasonable ? I can picture any
>>> number of scenarios with them that would result in a box that does not
>>> fit within the Screen dimensions. The only implementing code I have seen
>>> checks to that the width & height are >= 1. Can I/Should I handle -x
>>> values ? What if the requested bounds exceed the screen ?
>>> If we are making assumptions that the requested box is inside the
>>> screen.... then why don't we document that fact and add a check in the
>>> Robot class (instead of relying on the native impls).
>>> If we are assuming the requested box does not have to lie within the
>>> screen bounds - what should the returned values be for the pixels
>>> outside the screen ? Pixel Black ? (Currently I think Lens would return
>>> 0x instead of 0xff000000)
>>> My recommendation would be modify the JavaDoc contract to specify that
>>> the x,y and x+width, y+height must be within the screen bounds, with an
>>> IllegalArgumentException if out of bounds. This would be checked in
>>> Robot, prior to calling the native impls.
>>> This code is "internal" API, so I expect the real impact would be on SQE.

Reply via email to