Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

How to convert SetNextFocusable to FocusTraversalPolicy?

Status
Not open for further replies.

ModelTrains

Programmer
Nov 12, 2002
40
0
0
US
We have a Java 1.3 application that is being converted to 1.4.2_11 (or possibly 1.4.2_12). The app uses SetNextFocusableComponent over 400 times in JDialogs, JFrames, and JPanels. The users require custom Tab orders on several screens, a.k.a Column 1, top-to-bottom, then Column 2 top-to-bottom on a Dialog. (columns of individual components, not a table) This is causing a problem in the testing of the upgraded app.

Is there a "simple" way of converting the SetNextFocusables to the new Traversal policy? (Some JPanels have 20+ method calls. A JDialog usually has 2-4 JPanels)

I don't post often, so please let me know if you need more information.

Mike
 
Mmmm. If you want to keep the 'setNextFocusable' calls, maybe you could subclass JPanel, JFrame etc and re-introduce this method. This 'new' method would maintain a FocusTraversalPolicy which can interpret the focus order depending on which components are passed to it. You'd have to change all your classes effected so they inherit/utilise your new derived class, but this may be less changes for you.

I've no time to try this out myself, but I'm sure some of the other chaps here will poke holes in it if it's a daft suggestion.

Tim
 
No, I don't need to keep 'setNextFocusable', but I am looking for the most time-efficient way to convert 400 method calls in about 125 classes.

By design:
(I didn't do it) The application MOSTLY consists of dialogs containing data entry panels and button panels. Since the app was written in 2000-2001 using Java 1.3, other programmers have come along and added a data entry component (textField,checkBox,etc...) directly on the dialog. Now the users still want a customized way to tab through their screen. The initials for the application is TSS, and everything is overwritten:

Example:
class TSSDialog extends JDialog() {}
class TSSPanel extends JPanel() {}

class myActualFrontEndDialog extends TSSDialog() {}

The Problem:
When we did a build of the application in java 1.4, strange things happened, as expected. On dialogs with the setNextFocusable, the TAB key works within a panel, but if you TAB on the last field in a panel, the focus 'disappears'. If you TAB again, it re-appears in another panel. The setNextFocusable is at the panel level in most cases.

The question re-worded:
I am new to java 1.4. Do I put the FocusTraversalPolicy() on the dialog, each panel, both, or 'it depends'? Examples from Sun work great when you don't have a multi-tiered app.

Thanks in advance for your help!
Mike, java-developer-with-a-deadline
 
I didn't mean to imply that you had a desire to keep this method. I merely proposed a way of re-instating it so as to enable you to keep the majority of your code unchanged.

Tim
 
I think the way to go is implementing a FocusTraversalPolicy.

Cheers,
Dian
 
... which is what a derived class of JDialog would do, using its own setNextFocusable method to configure it.

I clean approach would be, as you say Dian, to implement one or more FocusTraversalPolicy derived classes and remove all existing setNextFocusable calls.



Tim
 
I know what I'm talking about. I still have nightmares with my last migration project, what a pain where you can imagine.

I think in this cases, it really worths starting things from the beginning instead of trying to do a hack that in the end will involve much more work.

But this is just an opinion, of course, each prohect is a new world.

Cheers,
Dian
 
Dian,
My nightmare is just beginning...

Does anyone have an example of a JDialog with two JPanels that you can successfully tab inside and between data-entry and button objects on the panels?
 
From what I've read of the FocusTraversalPolicy interface, it should be a matter of creating your own implementation of this and setting it on the JDialog. You would presumably have a method on this implementation allowing you to add components to it, with the order of addition determining the traversal as the simplest strategy. This class could be used in many places where you want to control focus traversal.

Tim
 
Hi!

I have solved this problem for all times - for myself.
Your problem is that you're not starting from scratch - you already have a lot of code, changing is always troublesome.

Still I believe that my "architecture" is not as much effort to change to as it may seem, since you can do the same procedure on all your windows/frames:
- after developing a "backgroundpanel"-class you just move everything into that panel.
- Write a focus-order-method ONCE for the frame.
- the frame is responsible for getting information about "who-is-ready-who-is-next", done by a FocusListener in every frame (always the same, only need to copy...)

----------------------------------------------
This is my approach:

Every dialog, window, errormsg-pop-up-whatever etc. is put in a background-JPanel. This panel holds functionality:
- which JComponent has the focus
- which JComponent will get it next
- method "JComponent getNextFocusComponent()"

The frame has the FocusListener, gets the focusLost-Information, asks the panel "who next?" and
sets the next focus through JComponent.requestFocus();
------------------------------------------------

This may be a little short for an explanation, but shows all necessary action. Keep in mind: you might have to do a lot of changes, but most of them will be simple copy or "put-inside"-changes.

The real trick is requestFocus() under control of the FRAME only. THIS MAY BE DELEGATED TO ANY COMPONENT THRU A "SETFOCUS()-METHOD WITHOUT ANY PROBLEMS. It makes focus control absolutely save, no difficult to understand problems thru Listener-caused (order-related) issues that lead to endless loops any more (as encountered when focus-control takes place or is initiated inside the components via focusGained/Lost() )!

Other benefits: absolutely readable (for other programmers later on)

bad:
- you create your own mechanism instead of using the standard way (as it was developed by clever people), solution looks primitive
- you may need a lookup-table (focusable components)
for the background-panel
- the frame may need a lookup-table of panels

---- but this really depends on your implementation!!!

Sorry - no time to extract code from my application since I had to remove too much to make it readable, but I hope you get the idea.

It's always fun to have complete control...

Andy
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top