In my applet, I have trace statements in focusGained/lost methods
indicating isEventDispatchThread value, the component and opposite
component associated with the event, as well as the current focus owner
and the permanent focus owner. I'm finding that on a focus gain, the
event component is not necessarily the same as the current focus owner.
The isEventDispatchThread value is true in every case which is an
assurance to me that the invoked method is thread safe.
More specifically, let's say I have JButtons B1, B2, B3 and JTextFields
F1, F2 and F3. Here's a sequence of actions:
1. Focus is on F3. Click on button B1. The program logic requests focus
for field F1. In reality, the focus ends up with B3. The trace shows
that the last thing that happened was a permanent focus gain on F3 (opp
component B1) with B3 being the current focus owner. B3 is the button
after B2. No caret is seen anywhere but field F1 is clickable.
2. Click on button B2. The program logic directs focus to F2. In
reality, the keyboard focus and a blinking caret ends up with F2, and
also a blinking caret at F1! The last thing in the trace is a focus
gain on F2 (opp component null) with current focus owner null, followed
by a focus gain on F1 (opp component B2) with current focus owner F2.
In a focus gain method is it normal to have an event component not be
the same as the current focus owner? Do I see 2 blinking carets because
focus was last gained on F1 but the current focus owner is F2? How can
I get just one blinking caret? Can somebody also tell me the difference
between event.getComponent() and event.getSource()?
Anup
Andrew Thompson - 30 Sep 2005 22:32 GMT
> In my applet,
...
> More specifically, let's say I have ..
..An URL perhaps, where we can see the applet?
That is generally much more specific than any
amount of descriptions. It might be handy to
link to your code as well.
Anup - 03 Oct 2005 19:46 GMT
> > In my applet,
> ...
[quoted text clipped - 4 lines]
> amount of descriptions. It might be handy to
> link to your code as well.
I agree that an applet in hand is much better. However, corporate
policies prohibit me from having a non-employee gain access inside the
corporate firewall.
Anup
Andrew Thompson - 03 Oct 2005 20:14 GMT
>>>In my applet,
..
>>....URL perhaps, where we can see the applet?
...
> I agree that an applet in hand is much better. However, corporate
> policies prohibit me from having a non-employee gain access inside the
> corporate firewall.
Do corporate policies prohibit you from preparing
an example[1] of the problem that others *can* see?
(Put it *outside* the firewall.)
Note that your example also does not require
'..tabs and popups, and a few hundered components,',
but just enough components to display the problem..
For tips, see [1] <http://www.physci.org/codes/sscce.jsp>.
Thomas A. Russ - 03 Oct 2005 23:00 GMT
> > > In my applet,
> > ...
[quoted text clipped - 8 lines]
> policies prohibit me from having a non-employee gain access inside the
> corporate firewall.
Hmmm. Perhaps the corporate policy makers need to spring for some funds
to let you hire a Java consultant who would then be allowed to see the
code and provide the advice you need?

Signature
Thomas A. Russ, USC/Information Sciences Institute
Roedy Green - 01 Oct 2005 01:58 GMT
>1. Focus is on F3. Click on button B1. The program logic requests focus
>for field F1. In reality, the focus ends up with B3. The trace shows
>that the last thing that happened was a permanent focus gain on F3 (opp
>component B1) with B3 being the current focus owner. B3 is the button
>after B2. No caret is seen anywhere but field F1 is clickable.
It sound as bit as if you give focus to something, but it slides off
to the next component in the traversal order because it does to have
permission to hold focus for some reason.
You have been bashing your head against a wall on this for some time.
Here is a desperate measure way out. Implement a FocusTraveral policy.
Perhaps that will tame things, or at least make more explicit what is
going on. Focus has been the other lemon of Java besides
java.util.Date.
At least then, by defining your order appropriates perhaps you can
guide slides to where you want hem to go..

Signature
Canadian Mind Products, Roedy Green.
http://mindprod.com Again taking new Java programming contracts.
Anup - 03 Oct 2005 19:52 GMT
> It sound as bit as if you give focus to something, but it slides off
> to the next component in the traversal order because it does to have
[quoted text clipped - 5 lines]
> going on. Focus has been the other lemon of Java besides
> java.util.Date.
I'm all for a FocusTraversalPolicy. The catch is that it will be too
disruptive for an already complicated applet that handles 5 forms, each
form having tabs and popups, and a few hundered components, some of
them conditional.
Anup
Roedy Green - 04 Oct 2005 09:43 GMT
>I'm all for a FocusTraversalPolicy. The catch is that it will be too
>disruptive for an already complicated applet that handles 5 forms, each
>form having tabs and popups, and a few hundered components, some of
>them conditional.
I am getting confused here. There is someone I have been talking whose
problem turned out to be having TWO event processing threads. What
that you? If it was, we first of all have to clear that up.
If it was not you, you should do a check to see if that is happening
to you also. Please see http://mindprod.com/jgloss/swingthreads.html

Signature
Canadian Mind Products, Roedy Green.
http://mindprod.com Again taking new Java programming contracts.
Anup - 05 Oct 2005 13:39 GMT
> >I'm all for a FocusTraversalPolicy. The catch is that it will be too
> >disruptive for an already complicated applet that handles 5 forms, each
[quoted text clipped - 4 lines]
> problem turned out to be having TWO event processing threads. What
> that you? If it was, we first of all have to clear that up.
Roedy, yes that was me. Since I'm actively discussing on the other
post, I will stop this one.
Anup