Re: java component focus lost event and tabbedPane design problem
From: Kleopatra (fastegal_at_gmx.de)
Date: 11/13/03
- Next message: Peter the Swede: "ImageIO, error when trying gif"
- Previous message: eeyimaya: "is active rendering for only fullscreen applications?"
- In reply to: Krick: "Re: java component focus lost event and tabbedPane design problem"
- Next in thread: Krick: "Re: java component focus lost event and tabbedPane design problem"
- Reply: Krick: "Re: java component focus lost event and tabbedPane design problem"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Thu, 13 Nov 2003 12:06:08 +0100
Krick wrote:
>
> >
> > And I'm not convinced: hooking into tabbedPane.setSelectedIndex and
> > doing whatever will not prevent the change of tab if the selection is
> > changed via the selectionModel.
> >
>
> I did try it your way. I didn't work for what I'm trying to do.
Then you didn't follow my outline:
"2) unfortunately that does not help with JTabbedPane because
setSelectedIndex does not care about InputVerifiers ... but you can
easily make it so by setting a custom SingleSelectionModel that simply
does not change the selectedIndex if the current focus owner is a child
of the currently selected tab, has an InputVerifier and objects to the
focus yield."
I never saw any code from you that a) checked if the focusOwner is a
child of the tab and b) if so ask its InputVerifier if it's okay to
leave.
> Your
> solution seems to work well if you only have input verifiers that
> simply return true or false and you use that as an indication of
> whether you can switch tabs.
>
no, it doesn't make a difference.
>
> I don't understand why you think my method will not work.
> It's not really experimentation.
because I tested it. It's misbehaving in (at least) 2 situations:
1) when the focus is on an objecting child of the selected tab and the
selection is changed via model.setSelectedIndex() the tab is changed
before popping up the dialog - that's the very problem you wanted to
solve.
2) when the focus is on widget _outside_ of the tabbed pane then
selecting another tab does invoke the inputVerifier of that widget.
> I suppose that someone could circumvent my method by calling
> JTabbedPane.getModel() and then calling setSelectedIndex() directly
> through the model. Though, I can't think for the life of me why
> someone would to that.
>
that's no "circumvention" - it's the way swing is supposed to work: the
model rules! So whenever you find something's wrong, first go for the
model to fix it. In fact, tabbedPane.setSelectedIndex is doing too much
internal state change - a clean implementation would set the model's
index and do any state change in a method listening to the model.
> If that's the case, I could very easily extend setSelectedIndex in a
> model instead of in the JTabbedPane itself. Regardless, my way seems
> a lot simpler.
>
Unfortunately simple solutions often don't solve the problem completely.
It's up you to decide if you can live with the incompleteness.
> Ultimately, the problem boils down to one simple issue...
>
> When someone tries to switch tabs (either through a mouse click or
> programmatically), the tab control needs to request focus so that
> any
> input validators are consulted before the switch is allowed to
> happen.
sorry - but that's incorrect in 2 (again: at least) details:
a) you included a wrong assumption about the solution into your problem
analysis: focus of the tab is a side-effect of your approach but not
part of the problem. In fact, what to do with focus on selection changes
depends on context.
b) you don't (or at least should not) want to invoke _any_ validators
but only those attached to the focused child of the currently selected
tab
>
> Why this the java code isn't doing this already points to a much
> larger design problem with Swing and component focus.
no, I disagree: focus should not be forced unconditionally onto the tab
with every selection, f.i. if the focus is somewhere outside of the tab
then selection changes should do nothing to change the focus, at least
not if the selection change is done programmatically. What to do if the
change is the result of a mouse-click is arguable and depends on
requirements.
What it should do though is to handle the case when the focus has been
on the tab or any of its children consistently, the current
implementation is definitely buggy.
> Tons of issues
> remain in spite of the new focus system. Don't even get me started on
> the problems I'm having with JTable and DefaultCellEditors. It's not
> pretty.
I agree. But things improved considerably over versions. Some of the
deeper lying problems with focus are announced to be fixed in 1.5. Let's
hope it's true.
Greetings
Jeanette
- Next message: Peter the Swede: "ImageIO, error when trying gif"
- Previous message: eeyimaya: "is active rendering for only fullscreen applications?"
- In reply to: Krick: "Re: java component focus lost event and tabbedPane design problem"
- Next in thread: Krick: "Re: java component focus lost event and tabbedPane design problem"
- Reply: Krick: "Re: java component focus lost event and tabbedPane design problem"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
|
