Wanted: editable text area/pane with external Document Content AND custom DefaultEditorKit

[Chris Kimball]

I'd like to set the AbstractDocument.Content and a modified DefaultEditorKit into a Swing text area or edit pane for a text/plain document. The idea is to modify a few Actions, such as DeletePrevCharAction in the DefaultEditorKit and have a Content with an external array. I've looked at the sources, but get thwarted at every step.

For example, JTextArea allows me to specify the Content but doesn't allow setting a custom version of DefaultEditorKit.

Similarly, the JTextPane allows a StyledDocument and forces a StyledEditorKit extending the DefaultEditorKit. I can extend the StyledEditorKit, but can't APPARENTLY override
the static DeletePrevCharAction subclass of DefaultEditorKit.

JEditPane allows (in principle) setting of the EditorKit, however, it forces its own default Document.

Many of the source files contain references to sun classes and SwingUtilities2 that don't seem to be available.

Any suggestions for an editable Swing text area with 1) a specifiable AbstractDocument.Content and 2) a specifiable DefaultEditorKit would be appreciated.

[Darryl Burke]

Chris Kimball wrote:The idea is to modify a few Actions, such as DeletePrevCharAction in the DefaultEditorKit and have a Content with an external array.

Can't be sure since this a rather advanced requirement, but I think my approach would be to try to change the KeyBinding for the <Backspace> key to associate a different Action.

Chris Kimball wrote:I can extend the StyledEditorKit, but can't APPARENTLY override the static DeletePrevCharAction subclass of DefaultEditorKit.

No, but you can override getActions() and replace the TextAction whose Action.NAME key is associated with a value DefaultEditorKit.deletePrevCharAction

[Chris Kimball]

The idea of overriding the getActions() method in an extension of StyledEditorKit was really helpful, thanks!

New Actions created for the StyledEditorKit extension required the Document Content (AbstractDocument.Content), so I added the Content as an instantiation parameter to the StyledEditorKit extension.

Thanks for your very useful idea!

Chris

[Darryl Burke]

Glad I could make a useful suggestion, and do let us know how it went!

[Chris Kimball]

Although the suggestions worked well, the idea of making a "clean" JTextPane seems unachievable. Here are two problems:

1. ActionEvents pass individual Strings every time a key is typed. While there's a strong hope that these residual one character Strings won't be retained in ordered sequence and will be garbage-collected, there's no avoiding them.

2. The communication between the EditorKit and the Viewer is by Segments. The Viewer provides a Segment to be filled, the Editor assigns a NEW char[] to the Segment.array, leaving the previous char[] to be garbage collected. These Segment arrays can be very long. There's no way (that I can see) to clear these Segment.char[] arrays with random characters BEFORE they go to the Editor. Even if such a cleaning was possible, it might degrade the display performance.

Maybe it's obvious, but I've concluded: Java Swing components will leave sensitive text on your machine.

Thanks for your inputs!

Chris

[Darryl Burke]

Chris Kimball wrote:I've concluded: Java Swing components will leave sensitive text on your machine.

Ah. So you're trying to create a 'JPasswordPane' that relies totally on primitives. I agree, it's probably not doable.

[Chris Kimball]

Exactly.

JPasswordField probably leaves the password on the machine IF the display characters are not obliterated.

Thanks,

Chris