-
Enhancement
-
Resolution: Fixed
-
P4
-
1.1.1, 1.1.2fcs, 1.1.4, 1.2.2, 1.3.0, 6
-
beta
-
generic, x86, sparc
-
generic, solaris_2.5.1, windows_nt, windows_xp
The problem we are having, and I'm sure many other users of
AWT will run in to this eventually, is this: We have several
components that we created using the ScrollPane: i.e.
ListControl, TreeControl, and GridControl. These
components are designed to display large amounts of data
- which is typical in real business applications. In Win32
(Windows95/WindowsNT), the ScrollPane currently limits
the client component to roughly 32000 pixels tall and/or
wide. This works out to about a 1600 record limit in a
GridControl (depends on font sizes), which is an
unacceptable limitation.
What this boils down to is this: A user can only see a
small portion of the data they want to display in a Grid, List,
or Tree. For a business database application development
tool, this is a STOP SHIP bug. JBuilder is a business
database development tool. We need this fixed right now.
The fix is pretty straightforward, and has to be rolled into
the Win32 implementation of AWT. Win32 uses a short to
represent the scroll position in the native Windows Scrollbar
widget. If the client component is larger than this, a scaling
factor needs to be factored in for all messages going
between the Java code and the native Win32 code. If fixed
correctly, there will be no compatability impact. Users' Java
code will simply not know about the pixel limitation under
Win32 - it should be nicely hidden.
----------------------------------------------
The test case is VERY simple to create, so I will merely
describe what is actually happening here... In Win32, the
native scrollbar uses a short int to represent the scroll
position. It is very common practice in Win32 programming
to subclass the scrollbar and incorporate a scaling factor
when the range value exceeds the short int limit (32K). The
ScrollPane's peer object does not have this scaling factor
built in, so it is limited to scrolling 32 thousand pixels in any
direction. This equates to roughly 1500 records (depends
on text height) on our GridControl or ListControl, which is
typically far below the total number of records being
displayed in a data table... this is a very nasty blocking bug
for us - and we cannot work around it without changes to the
native code in AWT for Win32.
To create a test case, put a simple subclass of Panel in a
ScrollPane, and return a figure larger than 32000 pixels wide
and/or high in getPreferredSize(). The ScrollPane has
serious problems with this case - and certainly shouldn't.
----------------------------
Please see the attachment for a reproduciable test case in Solaris.
This program displays the labels incorrectely in ScrollPane Panel.
----------------------------
Apr 23, 97: Customer is requesting a Work Around.
Name: krT82822 Date: 10/14/99
Hi Java Creators!
The Bug related to Scrollpane supporting Large Canvases was
first reported in April 1997. We had been told that it would be
fixed in 1.2 release. But it was not. This is a really serious
bug. Do not consider the severity of the bug based on number of
votes. This wasted lot of our development time. Why do not you
fix the existing bugs and go for a newer version? Ofcourse we
accept that it would be great if java has all current Technologies
in it. But if you have bugs then developers would loose interest
in Java. Definitely we should inform known bugs through BugParade.
But those bugs should not be there for ever. Are you seriously
trying on the bugs to which you have mentioned the status as in
progress (for example 4046446)? Similarly when we run an executable,
through C or C++ execl call, it would be executed as if it was
run from command line. It would take inputs from keyboard and
flush output to console window. Why should we get streams of the
process and manipulate them in Java when we do the same through
Runtime's exec? I felt so unhappy for this. Please reply for this
mail if you are really concerned about developer's plight. After
all i am not asking to improve its performance. I tested Hotspot
Client side and Server side JVM's. Felt JIT compiler better. I do
not mind for this.
regards,
syam
(Review ID: 96554)
======================================================================
AWT will run in to this eventually, is this: We have several
components that we created using the ScrollPane: i.e.
ListControl, TreeControl, and GridControl. These
components are designed to display large amounts of data
- which is typical in real business applications. In Win32
(Windows95/WindowsNT), the ScrollPane currently limits
the client component to roughly 32000 pixels tall and/or
wide. This works out to about a 1600 record limit in a
GridControl (depends on font sizes), which is an
unacceptable limitation.
What this boils down to is this: A user can only see a
small portion of the data they want to display in a Grid, List,
or Tree. For a business database application development
tool, this is a STOP SHIP bug. JBuilder is a business
database development tool. We need this fixed right now.
The fix is pretty straightforward, and has to be rolled into
the Win32 implementation of AWT. Win32 uses a short to
represent the scroll position in the native Windows Scrollbar
widget. If the client component is larger than this, a scaling
factor needs to be factored in for all messages going
between the Java code and the native Win32 code. If fixed
correctly, there will be no compatability impact. Users' Java
code will simply not know about the pixel limitation under
Win32 - it should be nicely hidden.
----------------------------------------------
The test case is VERY simple to create, so I will merely
describe what is actually happening here... In Win32, the
native scrollbar uses a short int to represent the scroll
position. It is very common practice in Win32 programming
to subclass the scrollbar and incorporate a scaling factor
when the range value exceeds the short int limit (32K). The
ScrollPane's peer object does not have this scaling factor
built in, so it is limited to scrolling 32 thousand pixels in any
direction. This equates to roughly 1500 records (depends
on text height) on our GridControl or ListControl, which is
typically far below the total number of records being
displayed in a data table... this is a very nasty blocking bug
for us - and we cannot work around it without changes to the
native code in AWT for Win32.
To create a test case, put a simple subclass of Panel in a
ScrollPane, and return a figure larger than 32000 pixels wide
and/or high in getPreferredSize(). The ScrollPane has
serious problems with this case - and certainly shouldn't.
----------------------------
Please see the attachment for a reproduciable test case in Solaris.
This program displays the labels incorrectely in ScrollPane Panel.
----------------------------
Apr 23, 97: Customer is requesting a Work Around.
Name: krT82822 Date: 10/14/99
Hi Java Creators!
The Bug related to Scrollpane supporting Large Canvases was
first reported in April 1997. We had been told that it would be
fixed in 1.2 release. But it was not. This is a really serious
bug. Do not consider the severity of the bug based on number of
votes. This wasted lot of our development time. Why do not you
fix the existing bugs and go for a newer version? Ofcourse we
accept that it would be great if java has all current Technologies
in it. But if you have bugs then developers would loose interest
in Java. Definitely we should inform known bugs through BugParade.
But those bugs should not be there for ever. Are you seriously
trying on the bugs to which you have mentioned the status as in
progress (for example 4046446)? Similarly when we run an executable,
through C or C++ execl call, it would be executed as if it was
run from command line. It would take inputs from keyboard and
flush output to console window. Why should we get streams of the
process and manipulate them in Java when we do the same through
Runtime's exec? I felt so unhappy for this. Please reply for this
mail if you are really concerned about developer's plight. After
all i am not asking to improve its performance. I tested Hotspot
Client side and Server side JVM's. Felt JIT compiler better. I do
not mind for this.
regards,
syam
(Review ID: 96554)
======================================================================
- duplicates
-
JDK-5064628 ScrolBar goes up in sudden when the value becomes greater than 65000
- Closed
-
JDK-4099201 Scroll Pane problems for large heights.
- Closed
- relates to
-
JDK-4006017 on Solaris/X11, the max win size is defined by an unsigned 16 bit int (64K)
- Closed
-
JDK-8301994 Remove unused code from awt_List.cpp
- Resolved