-
Enhancement
-
Resolution: Unresolved
-
P4
-
None
-
6u17
-
x86
-
windows_xp
java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Client VM (build 14.3-b01, mixed mode, sharing)
Does this problem occur on J2SE 5.0.x or 6.0? Yes / No (pick one)
Yes
Operating System Configuration Information (be specific):
Client: Microsoft Windows XP [Version 5.1.2600]
Bug Description:
RFE: Provide a way for a Table Cell Editor to start editing without the reposted event
When rendering numbers in cells we would like to just show the numbers.
When editing them we would like to use a number spinner.
The problem is when the user clicks close to the right side of the cell, the editor is returned one higher or lower than it should be due to the mouse click that started the editing getting reposted on the spinner buttons which were not visible at the time the user clicked.
Ideally when BasicTableUI wants to repost the event, the cell editor should be able to control how the event is reposted (so that if the user clicks between the 1 & 2 of 123 the editor cell editor will convert the event to the text field part of the spinner so that the caret appears between the 1 and the 2).
Sufficient would be a check asking the cell editor if it wants the event to be reposted or not.
As a workaround we are relying on shouldSelectCell(pressedEvent) getting called after the repost has been done (which is noted by the developer of BasicTableUI as completely odd).
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Client VM (build 14.3-b01, mixed mode, sharing)
Does this problem occur on J2SE 5.0.x or 6.0? Yes / No (pick one)
Yes
Operating System Configuration Information (be specific):
Client: Microsoft Windows XP [Version 5.1.2600]
Bug Description:
RFE: Provide a way for a Table Cell Editor to start editing without the reposted event
When rendering numbers in cells we would like to just show the numbers.
When editing them we would like to use a number spinner.
The problem is when the user clicks close to the right side of the cell, the editor is returned one higher or lower than it should be due to the mouse click that started the editing getting reposted on the spinner buttons which were not visible at the time the user clicked.
Ideally when BasicTableUI wants to repost the event, the cell editor should be able to control how the event is reposted (so that if the user clicks between the 1 & 2 of 123 the editor cell editor will convert the event to the text field part of the spinner so that the caret appears between the 1 and the 2).
Sufficient would be a check asking the cell editor if it wants the event to be reposted or not.
As a workaround we are relying on shouldSelectCell(pressedEvent) getting called after the repost has been done (which is noted by the developer of BasicTableUI as completely odd).