JDK-4431047 : JFormattedTextField should treat replace as an atomic edit
  • Type: Bug
  • Component: client-libs
  • Sub-Component: javax.swing
  • Affected Version: 1.4.0
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: solaris_7
  • CPU: sparc
  • Submitted: 2001-03-28
  • Updated: 2001-05-09
  • Resolved: 2001-05-09
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
1.4.0 beta2Fixed
Related Reports
Relates :  
Relates :  
Description
As a replace is typically seen as two edits, a remove than an insert, this can confuse the formatter and result in odd behavior. For example if you are editing a number, select all the text and replace it with a legal number often times it won't let you as the initial removal results in a bogus value.

Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: merlin-beta2 FIXED IN: merlin-beta2 INTEGRATED IN: merlin-beta2
14-06-2004

EVALUATION The following will be added to AbstractDocument: /** * Deletes the region of text from <code>offset</code> to * <code>offset + length</code>, and replaces it with <code>text</code>. * It is up to the implementation as to how this is implemented, some * implementations may treat this as two distinct operations: a remove * followed by an insert, others may treat the replace as one atomic * operation. * * @param offset Location in Document * @param length Length of text to delete * @param text Text to insert, null indicates no text to insert * @param attrs AttributeSet indicating attributes of inserted text, null * is legal, and typically treated as an empty attributeset, * but exact interpretation is left to the subclass * @exception BadLocationException the given position is not a valid * position within the document * @since 1.4 */ public void replace(int offset, int length, String text, AttributeSet attrs) throws BadLocationException; Similarly javax.swing.text.DocumentFilter will get (there is no @since 1.4 here as DocumentFilter is new in 1.4): /** * Invoked prior to replacing a region of text in the * specified Document. Subclasses that want to conditionally allow * replace should override this and only call supers implementation as * necessary, or call directly into the FilterBypass. * * @param fb FilterBypass that can be used to mutate Document * @param offset Location in Document * @param length Length of text to delete * @param text Text to insert, null indicates no text to insert * @param attrs AttributeSet indicating attributes of inserted text, * null is legal. * @exception BadLocationException the given insert position is not a * valid position within the document */ public void replace(FilterBypass fb, int offset, int length, String text, AttributeSet attrs) throws BadLocationException; And javax.swing.text.DocumentFilter.FilterBypass will get: /** * Deletes the region of text from <code>offset</code> to * <code>offset + length</code>, and replaces it with * <code>text</code>. * * @param offset Location in Document * @param length Length of text to delete * @param text Text to insert, null indicates no text to insert * @param attrs AttributeSet indicating attributes of inserted text, * null is legal. * @exception BadLocationException the given insert is not a * valid position within the document */ public abstract void replace(int offset, int length, String string, AttributeSet attrs) throws BadLocationException; scott.violet@eng 2001-04-24
24-04-2001