
Signature
And in short, I was afraid.
> There seems to be no easy way to have TAB and shift-TAB act just as
> normal focus traversal keys for a JTextArea/JEditorPane.
[quoted text clipped - 3 lines]
> TraversalKeys) from the set of focus traversal keys, i.e. non-editable
> components *always* have them, editable ones *never*.
make sure to reset the appropriate sets of traversal keys to your custom
sets (can be null to let the KeyboardFocusManager click in with the
defaults) _after_ the uidelegates do. In dynamic environments (where the
editable/editorKit property change during runtime) that will be after
configuring the editorPane and in a property change listener that
invokes the reset.
BTW, any idea why the update only interferes when the editorKit is an
instance of DefaultEditorKit?
> 1. Surely it should be configurable whether one wants the user to
> inserts tabs (or, more generally, to have TAB handled by an editor
> kit action), or whether it it should be a focus key.
>
> Never mind the specifics, should it e configurable whether the focus
> traversal keys are overridden (no matter what for)?
I think so.
> 2.
>
> http://developer.java.sun.com/developer/bugParade/bugs/4838730.html
>
> What was the bug?
hmm, what do you mean?
> What is "closed, fixed"?
fixed in tiger :-) i.e. custom settings will not be overridden.
Greetings
Jeanette
Christian Kaufhold - 27 Jan 2004 17:06 GMT
> BTW, any idea why the update only interferes when the editorKit is an
> instance of DefaultEditorKit?
Cluelessness? (It seems utterly pointless: While DefaultEditorKit defines
an action to be mapped to TAB, subclasses need not do so, and custom
editor kits not subclassing DefaultEditorKit can just as well define such
an action, can even take the one from a DefaultEditorKit since the actions
are not bound to a specific editor kit).
>> http://developer.java.sun.com/developer/bugParade/bugs/4838730.html
>>
>> What was the bug?
>
> hmm, what do you mean?
I was somewhat confused. But the evaluation sounds as if setting the
focus traversal keys was the fix and not the problem.
Christian
Kleopatra - 27 Jan 2004 17:33 GMT
> > BTW, any idea why the update only interferes when the editorKit is an
> > instance of DefaultEditorKit?
>
> Cluelessness?
<g>
> (It seems utterly pointless: While DefaultEditorKit defines
> an action to be mapped to TAB, subclasses need not do so, and custom
> editor kits not subclassing DefaultEditorKit can just as well define such
> an action, can even take the one from a DefaultEditorKit since the actions
> are not bound to a specific editor kit).
Full ACK - thanks, just thought I had overlooked something obvious.
Greetings
Jeanette