-
Enhancement
-
Resolution: Duplicate
-
P3
-
None
-
1.2.0
-
generic
-
generic
Execute SwingSet demo with remote JAR files and select TableView demo.
Select the following checkboxes:
- Column selection
- cell selection
Note that arrow keys allow you to navigate up and down the LastName column
with no problems. But PageUp and PageDown does not move the focus of the
cell but puts you into EDIT mode on the editable cell where your last focus is.
On IE4, according to customer, mouse clicks on other cell does not get out
of the editable cell. You are forced to type <Return> key to get out of EDIT
mode before you can navigate into another cell. However typing <Return>
also finalizes the changes on that cell and there is no recourse to fallback
to previous value.
On HotJava, mouse clicks on other cell allows you to get out of the editable cell. Once in EDIT mode, any changes in that cell not desired cannot be reset
to previous value by ESC key or mouse clicks to other cells. A mouse click
to another cell makes the last edit final. So there is no way to salvage
an accidental change on an editable cell. This is a pretty serious flaw
for the customer - they develop applications for naive computer users and
the GUI needs to be forgiving to common mistakes when editing JTable.
Customer has reproduced this problem with IE4 browser running SwingSet demo
on the JFC1.0 build. When running their application applet with JFC1.0build,
this bug causes the JTable to hang. I have not seen the hang yet with
the SwingSet demo but we can ask them to verify this against the JFC1.1 latest
build.
I can reproduce this (without the hang) on HotJava with the SwingSet demo
and the JFC1.1 build (dated 2/9/98) on Solaris sparc with a test setup
created by a Swing test engineer.
Select the following checkboxes:
- Column selection
- cell selection
Note that arrow keys allow you to navigate up and down the LastName column
with no problems. But PageUp and PageDown does not move the focus of the
cell but puts you into EDIT mode on the editable cell where your last focus is.
On IE4, according to customer, mouse clicks on other cell does not get out
of the editable cell. You are forced to type <Return> key to get out of EDIT
mode before you can navigate into another cell. However typing <Return>
also finalizes the changes on that cell and there is no recourse to fallback
to previous value.
On HotJava, mouse clicks on other cell allows you to get out of the editable cell. Once in EDIT mode, any changes in that cell not desired cannot be reset
to previous value by ESC key or mouse clicks to other cells. A mouse click
to another cell makes the last edit final. So there is no way to salvage
an accidental change on an editable cell. This is a pretty serious flaw
for the customer - they develop applications for naive computer users and
the GUI needs to be forgiving to common mistakes when editing JTable.
Customer has reproduced this problem with IE4 browser running SwingSet demo
on the JFC1.0 build. When running their application applet with JFC1.0build,
this bug causes the JTable to hang. I have not seen the hang yet with
the SwingSet demo but we can ask them to verify this against the JFC1.1 latest
build.
I can reproduce this (without the hang) on HotJava with the SwingSet demo
and the JFC1.1 build (dated 2/9/98) on Solaris sparc with a test setup
created by a Swing test engineer.
- duplicates
-
JDK-4117043 JTable needsa way to not commit to an edit.
-
- Closed
-