<Swing Dev> RFR: [9] [JDK-8081491] The case print incomplete.

Alexander Scherbatiy alexandr.scherbatiy at oracle.com
Wed Sep 23 09:16:20 UTC 2015


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?
    - Does the fix work correctly for a case when rMax has initial zero 
value but it is decremented on line 1857?

   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