<Swing Dev> RFR: [9] [JDK-8081491] The case print incomplete.
prasanta sadhukhan
prasanta.sadhukhan at oracle.com
Wed Sep 23 06:42:31 UTC 2015
I have updated the code as per your comment.
Please review this webrev
http://cr.openjdk.java.net/~psadhukhan/8081491/webrev.07/
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