Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsWhite Papers
Discussion GroupsFirst AidDatabasesJavaBeansGUIJava 3DVirtual MachineCORBASecurityToolsGeneral
Java DirectoryOpen Source ProjectsSample Book ChaptersUser GroupsWeb Resources
Related Topics
Databases.NETMore Topics ...

Java Forum / GUI / January 2004

Tip: Looking for answers? Try searching our database.

JTextComponents and focus traversal keys

Thread view: 
Christian Kaufhold - 26 Jan 2004 20:15 GMT
There seems to be no easy way to have TAB and shift-TAB act just as
normal focus traversal keys for a JTextArea/JEditorPane.

BasicEditorPaneUI/BasicTextAreaUI remove/add them depending on whether
the text component is non-editable/editable (BasicTextUI.updateFocus-
TraversalKeys) from the set of focus traversal keys, i.e. non-editable
components *always* have them, editable ones *never*.

I just want TAB (iff it is the "normal" focus traversal key) to act
as a focus key. I almost never want the user to insert tabulator
characters in plain text, and never in HTML-like text displayed by
JEditorPane.

Some thoughts:

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)?

2.

http://developer.java.sun.com/developer/bugParade/bugs/4838730.html

What was the bug? What is "closed, fixed"?

3.

I can add a KeyListener for TAB and then call transferFocus() etc.
manually, but
- it is not processes as a normal focus key: It is not handled by
KeyboardFocusManager.processKeyEvent
- more specifically, it does not consume the corresponding key-
Typed automatically (can this be done by hand?), that seems to be
all done by DefaultKeyboardFocusManager
- it is executed later (after InputMethodListeners and some other
pre-processing) in event-distribution.
- at the moment it seems to be hard-coded to TAB.

Christian
Signature

And in short, I was afraid.

Kleopatra - 27 Jan 2004 11:33 GMT
> 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


Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.