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 daniel.blauk...@oracle.com wrote:
We should be consistent about what we return, although I agree that that the
actual value doesn’t
Hi David,
Sorry to be getting to this so late. An uninitialized pixel is normally
considered to be black. If you throw an exception, clients will need to
either catch the exception or perform the same test that you are
performing before they call the API. Since this is not pubic API, no
It isn't public API now.. but keep in mind that making it public in
some way has been requested for over two years. See RT-17571
Since those issues have made the internal Robot API known, no doubt
people are using it. (We all know how well people listen to the
warnings about using internal APIs
On 3/26/14, Mar 26, 10:59 AM, Stephen F Northover wrote:
Hi David,
Sorry to be getting to this so late. An uninitialized pixel is normally considered to be
black. If you throw an exception, clients will need to either catch the exception or
perform the same test that you are performing
On 3/26/14, Mar 26, 12:53 PM, Stephen F Northover wrote:
I don't like implied contract code either but I also don't like exceptions
for cases like this. I would prefer that we return zero for pixels that are unspecified
as this seems better than testing screen bounds (which can get you in
For a one shot screen capture - we would pass in top left and width and
height to make the bottom right.
Currently this should work on Mac I am told, though what is in the out of
bounds pixels is not known.
And if we added a third tall screen to the left, life gets even more
complicated
Hi David,
sorry to keep you waiting with an answer from Embedded SQE.
I assume there will be no major impact on SQE since as you told and it
is true, most golden image tests we have are based on a window content.
Anyway from what I understood your implementation will be easily rolled
back if
On 3/21/14, Mar 21, 12:53 PM, David Hill wrote:
Having heard a little feedback, here is my proposal in the form of a review
request :-)
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
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 anthony.pet...@oracle.com wrote:
Hi David,
I don't think we're making any assumptions. We
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
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
11 matches
Mail list logo
