<Swing Dev> RFR: [9] [JDK-8081491] The case print incomplete.
prasanta sadhukhan
prasanta.sadhukhan at oracle.com
Wed Sep 23 09:26:33 UTC 2015
On 9/23/2015 2:46 PM, Alexander Scherbatiy wrote:
> On 9/23/2015 9:42 AM, prasanta sadhukhan wrote:
>> I have updated the code as per your comment.
>> Please review this webrev
>> http://cr.openjdk.java.net/~psadhukhan/8081491/webrev.07/
>
> - Is it possible that SwingUtilities.getUnwrappedParent(table)
> returns null?
I have not seen it. It will return at least JRootPane, I guess.
> - Does the fix work correctly for a case when rMax has initial zero
> value but it is decremented on line 1857?
rMax can have -1 from table.rowAtPoint() in which case it will be
changed to total rowCount so it will not be 0 before line 1857.
Regards
Prasanta
>
> Thanks,
> Alexandr.
>
>>
>> Regards
>> Prasanta
>> On 9/22/2015 7:01 PM, Alexander Scherbatiy wrote:
>>> On 9/21/2015 12:05 PM, prasanta sadhukhan wrote:
>>>>
>>>>
>>>> On 9/21/2015 2:20 PM, Alexandr Scherbatiy wrote:
>>>>> 18.09.2015 10:16, prasanta sadhukhan пишет:
>>>>>>
>>>>>>
>>>>>> On 9/17/2015 8:18 PM, Alexander Scherbatiy wrote:
>>>>>>> On 9/16/2015 2:04 PM, prasanta sadhukhan wrote:
>>>>>>>> Hi Alexander, Sergey,
>>>>>>>>
>>>>>>>> Waiting for your review on this.
>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8081491/webrev.06/
>>>>>>>
>>>>>>> Could you describe why the paint artifacts are drawn when a
>>>>>>> scroll pane is present?
>>>>>> I see that normally JTable has always been associated with
>>>>>> JScrollpane and it uses
>>>>>> // Paint the grid.
>>>>>> paintGrid(g, rMin, rMax, cMin, cMax);
>>>>>> // Paint the cells.
>>>>>> paintCells(g, rMin, rMax, cMin, cMax);
>>>>>> to paint the cells in the table.
>>>>>> When we scroll the table, rMin can be say 41 and rMax can be 43
>>>>>> so it expects to draw 3 rows with the above code (since the for
>>>>>> loop uses rows = rMin; rows <= rMax)
>>>>>> Also, sometimes rMin canbe 44 and rMax can be 44 too in which
>>>>>> case 1 row would be painted as per the above for loop
>>>>>>
>>>>>> but since I have modified the code to use (to make same rows to
>>>>>> show on console and in printed page)
>>>>>>
>>>>>> // Paint the grid.
>>>>>> paintGrid(g, rMin, rMax-1, cMin, cMax);
>>>>>> // Paint the cells.
>>>>>> paintCells(g, rMin, rMax-1, cMin, cMax);
>>>>>>
>>>>>> it paints only 2 rows (or 0 rows in case rMin=rMax=44 where
>>>>>> rMax-1 is 43 so for loop will not be executed) and when we go on
>>>>>> scrolling, 1 less row gets painted always than what it expects
>>>>>> resulting in artifacts.
>>>>>> So, I have kept the same code for JTable when it has scrollpane
>>>>>> (which was till now the case)
>>>>>
>>>>> - Does it mean if the initialpaintGrid()/Cell() methods are
>>>>> used there are artifacts when a table is not used with JScrollPane?
>>>> When table is not used with JScrollPane, there is no change of
>>>> table visible rows (since user is not scrolling the table) so there
>>>> is no artifacts if table does not have jscrollpane.
>>>>> - It is not necessary to add isScrollPanePresent varibale if
>>>>> it is used only once
>>>> I did not understand. It's a variable and not a function. So, what
>>>> you are proposing me to do?
>>>
>>>
>>> It is possible just to use
>>> -----------------------------
>>> + if (some expression) {
>>> // do something
>>> }
>>> -----------------------------
>>> instead of
>>> -----------------------------
>>> + boolean isScrollPanePresent = true;
>>> + if (some expression) {
>>> + isScrollPanePresent = false;
>>> + }
>>> + if (isScrollPanePresent) {
>>> // do something
>>> }
>>> -----------------------------
>>>
>>> In your case it is even better just to update the rMax according to
>>> is scroll pane presence.
>>>
>>> Thanks,
>>> Alexandr.
>>>
>>>>
>>>> Regards
>>>> Prasanta
>>>>>
>>>>> Thanks,
>>>>> Alexandr.
>>>>>>
>>>>>> Regards
>>>>>> Prasanta
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Alexandr.
>>>>>>>>
>>>>>>>> Regards
>>>>>>>> Prasanta
>>>>>>>> On 9/15/2015 10:55 AM, prasanta sadhukhan wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 9/14/2015 12:48 PM, prasanta sadhukhan wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 9/11/2015 2:20 PM, prasanta sadhukhan wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 9/10/2015 4:48 PM, Sergey Bylokhov wrote:
>>>>>>>>>>>> On 10.09.15 13:35, prasanta sadhukhan wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 9/10/2015 3:42 PM, Sergey Bylokhov wrote:
>>>>>>>>>>>>>> On 10.09.15 9:36, prasanta sadhukhan wrote:
>>>>>>>>>>>>>>> Please review the modified webrev which solves this
>>>>>>>>>>>>>>> artifacts.
>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8081491/webrev.05/
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> What will happen if the table will be added to the jpanel
>>>>>>>>>>>>>> and the
>>>>>>>>>>>>>> jpanel will be added to JScrollPane? Will this
>>>>>>>>>>>>>> configuration work as
>>>>>>>>>>>>>> expected?
>>>>>>>>>>>>>>
>>>>>>>>>> Please review which takes care of this configuration
>>>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8081491/webrev.06/
>>>>>>>>> Gentle reminder for review request.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I also added a reg test for this regression but I am not
>>>>>>>>>>>>>>> able to create
>>>>>>>>>>>>>>> a automated testcase to deal with the scrolling
>>>>>>>>>>>>>>> artifacts, so I added a
>>>>>>>>>>>>>>> manual test.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I suggest to try to automate it somehow. Probably make
>>>>>>>>>>>>>> some small
>>>>>>>>>>>>>> unity test? Or using robot?
>>>>>>>>>>>>> Even with Robot or unity test, how will I check the
>>>>>>>>>>>>> artifact has
>>>>>>>>>>>>> happened? THis is a visual problem. I do not know how to
>>>>>>>>>>>>> test it
>>>>>>>>>>>>> automatically.
>>>>>>>>>>>>
>>>>>>>>>>>> In case of unit test you can check the return value of some
>>>>>>>>>>>> methods or the state of the objects which are cause the
>>>>>>>>>>>> artifacts. For test with robot, you can fill all rows of
>>>>>>>>>>>> table in some color, then scroll it, and check the color of
>>>>>>>>>>>> the table using robot.getPixelColor().
>>>>>>>>>>> Thanks Sergey for the suggestion. I am trying to use Robot
>>>>>>>>>>> to test this artifacts. But when I use Robot to scroll
>>>>>>>>>>> up/down, the artifacts are not seen even when the scrollbar
>>>>>>>>>>> moved up and down. But manually if I scroll, I can see the
>>>>>>>>>>> artifacts. Can you please let me know if the attached
>>>>>>>>>>> testcase is missing something?
>>>>>>>>>>>
>>>>>>>>>> Regards
>>>>>>>>>> Prasanta
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --Prasanta
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Regards
>>>>>>>>>>>>>>> Prasanta
>>>>>>>>>>>>>>> On 9/8/2015 4:27 PM, Sergey Bylokhov wrote:
>>>>>>>>>>>>>>>> Hi, Prasanta.
>>>>>>>>>>>>>>>> Just before the push of this fix I made small pit, and
>>>>>>>>>>>>>>>> found a
>>>>>>>>>>>>>>>> regression. Please run the SwingSet2, open JTable demo,
>>>>>>>>>>>>>>>> and scroll the
>>>>>>>>>>>>>>>> table. You will see some artifacts.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 08.09.15 13:13, prasanta sadhukhan wrote:
>>>>>>>>>>>>>>>>> Thanks Sergey for pointing this.
>>>>>>>>>>>>>>>>> I have taken care of this plus formatting in for loop.
>>>>>>>>>>>>>>>>> Please have a look
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8081491/webrev.04/
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Regards
>>>>>>>>>>>>>>>>> Prasanta
>>>>>>>>>>>>>>>>> On 9/8/2015 3:32 PM, Sergey Bylokhov wrote:
>>>>>>>>>>>>>>>>>> Hi, Prasanta.
>>>>>>>>>>>>>>>>>> A few small notes:
>>>>>>>>>>>>>>>>>> - BasicTableUI: typo "1850 // otherwise 1 extra rows
>>>>>>>>>>>>>>>>>> are ptinted"
>>>>>>>>>>>>>>>>>> - ImageableAreaTest: the test instructions have copy
>>>>>>>>>>>>>>>>>> pasted numbers
>>>>>>>>>>>>>>>>>> 1/2/2/2 etc.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On 08.09.15 12:43, prasanta sadhukhan wrote:
>>>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
More information about the swing-dev
mailing list