Thanks for your review.
I need +1 for this. Alexander Z/Sergey, can you please approve this fix?
Regards
Prasanta
On 9/8/2015 3:02 PM, Alexander Scherbatiy wrote:
The fix looks good to me.
But you need to properly format spaces in the 'for' loop on line
TablePrintable:410 before the push.
Thanks,
Alexandr.
On 9/8/2015 12:26 PM, prasanta sadhukhan wrote:
On 9/7/2015 5:50 PM, Alexander Scherbatiy wrote:
On 9/7/2015 9:23 AM, prasanta sadhukhan wrote:
I guess it will be same but anyways have modified to use
visibleBounds.getLocation() to be on safeside as we are dealing
with visible region for this fix.
Please review the updated webrev
http://cr.openjdk.java.net/~psadhukhan/8081491/webrev.02/
TablePrintable:
- Could the rMin be equal to -1?
This should never happen so long bounds intersects the clip but as
done in BasicTableUI, I have added the check just in case
- Line: 406 int rowHeight = (rMax-rMin) * table.getRowHeight();
Rows can have different height in the table. Could you also
add a test for the this case too?
Added test for this case too.
Please review this webrev:
http://cr.openjdk.java.net/~psadhukhan/8081491/webrev.03/
Regards
Prasanta
Thanks,
Alexandr.
Regards
Prasanta
On 9/4/2015 8:57 PM, Alexander Scherbatiy wrote:
Could the clip.getLocation() be differ from them
visibleBounds.getLocation()?
Thanks,
Alexandr.
On 9/4/2015 3:32 PM, prasanta sadhukhan wrote:
Any reviewers for this please?
On 9/2/2015 5:06 PM, prasanta sadhukhan wrote:
Hi,
Can this fix be reviewed?
Regards
Prasanta
On 8/28/2015 4:48 PM, prasanta sadhukhan wrote:
On 8/26/2015 6:24 PM, Alexander Scherbatiy wrote:
On 8/25/2015 1:51 PM, prasanta sadhukhan wrote:
On 8/25/2015 3:53 PM, Alexander Scherbatiy wrote:
On 8/24/2015 2:23 PM, prasanta sadhukhan wrote:
Hi All,
Bug: https://bugs.openjdk.java.net/browse/JDK-8081491
webrev:
http://cr.openjdk.java.net/~psadhukhan/8081491/webrev.00/
This seems to be a hidden JTable bug in which if the user
does not call pack() or set a ScrollPane() for JTable and
rather use JFrame.setSize() smaller than table size then it
was found that some of the rows which cannot be fitted in
1st page cannot get printed on 2nd and subsequent pages
resulting in blank cells to be printed after 1st page.
It was found that BasicTableUI checks for table bounds to
fall within the clip and if they do not intersect, it bails
out from painting the table cells.
What is the reason that the graphics clip does not
intersect the table bounds during printing in the provided
test case?
The testcase does table.setSize(600,800) whereas frame
setSize is 400,600 .
For 1st page, the clip was 0,0,384,752 and bounds was
0,0,384,562 so they intersect and there's no problem in
printing the rows in 1st page.
After the 1st page is printed, the clip is set to
0,752,384,48 since we have printed the rows that we can fit
in 1st page and the next set of rows are to be printed while
bounds remains at 0,0,384,562 because JComponent getBounds is
returning the visible frame bounds which did not change.
The !bounds.intersects(clip) check prevents printing of
table rows which are not visible on the frame.
It seems that the issue is that extra rows which are not
shown in the frame are printed on the first page.
It means that the printed rows and columns should be
calculated for the table bounds and clip intersection.
The test can be updated to mention that only visible part
of the table should be printed.
Have modified the code to print only the rows that are
displayed on console. Also updated the test to mention the
same. Please review the updated webrev.
http://cr.openjdk.java.net/~psadhukhan/8081491/webrev.01/
Regards
Prasanta
Thanks,
Alexandr.
Please, also mention in the email title JDK version for
which the fix is provided.
Done
Regards
Prasanta
Thanks,
Alexandr.
I devised a solution whereby it will not bail out till
either rows or columns are still left to be printed on
subsequent pages . Please review and let me know if it's ok.
Regards
Prasanta
