Working around Component.setEnabled().

Question

I'm having a lot of issues arising from events generated from setEnabled() due to the fact that they get added to the end of the queue. For some reason even running code using SwingUtilities.invokeLater() after the setEnabled() doesn't work, the offending code still ends up executed after what was in invokeLater(). I believe it's part of the UI's reaction to the property change but I haven't pin pointed it yet.
For example:
myJTextField.setEnabled(false);
SwingUtilities.invokeLater(new Runnable() {
    public void run() {
        myFocusCycleRoot.transferFocusDownCycle();
});Results in focus being transferred to myFocusCycleRoot's default component, then transferred to the component after myJTextField. This leads me to believe that code is run at the end of the queue and then THAT code runs code that gets added to the end of the queue which causes the focus to transfer. The code in invokeLater() would then end up executed between the two. Any ideas for a solution?

Answer 1

if I'm reading the snippet in Manning's book correct,
transferFocusDownCycle()
takes you to the next focus cycle,Either you are reading wrong or Manning is wrong.
Transfers the focus down one focus traversal cycle. If this Container is a focus cycle root, then the focus owner is set to this Container's default Component to focus, and the current focus cycle root is set to this Container. If this Container is not a focus cycle root, then no focus traversal operation occurs.
We're calling it on a focus cycle root and consequently the default component will have focus. According to the focus traversal policy installed the default component will be the first component found that is enabled, or null if none are enabled.
not the next component (again, if I'm reading
correctly, is what you're trying to do)Nope. Not what I want at all. That's the problem, setEnabled(false) indirectly results in focus transferring to the next component after focus has already been changed to the default component.
Let's say we have 10 components and we'll call them component 1 through component 10. Component 1 is the first component in the policy, component 10 is the last. The default component is the first enabled component found when iterating from 1 to 10. Now, a user may be viewing these components and may take some action. This action will result in those 10 components having their fields repopulated and some of them disabled based upon information from a model. Likewise, some of the components that may have been disabled prior to the user action may become enabled. Once this happens we want the focus to move to the default component, which may be before, or after, or even the same as the current component depending on what all was enabled/disabled. Unfortunately, if the current component happens to be disabled in this process then that disabling will cause focus to transfer to the next component after we've changed focus to the default component. So let's say we have thus:
Components 1-5 disabled component 6-10 enabled. The user is on component 6. The user takes said action. Now components 3, 4, 7, 9, 10 become enabled. Likewise components 1, 2, 5, 6, 8 become disabled. The default component will be the first enabled, 3, and using transferFocusDownCycle() the default component receives focus. So now the focus is on 3. However, 6 had focus before and was disabled, and somehow it's code only now results in transfering focus to 7, so it jumps to 7.
Now consider what happens if 7 became disabled. It happens before it has focus, so the focus transfer from 7 isn't triggered, but 7 still receives focus despite being disabled because the trigger in 6 happened before it was disabled. Now 7, a disabled component, receives focus but is disabled so focus ends up in limbo and nothing has it anymore.
Yes, it's a freaking nightmare and I'm about ready to file a bug because the more I think about it the dumber it sounds. Why should setEnabled() transfer focus? That should be left to the client to decide whether or not focus should even happen. Worst part of it is because of the way it's written if the next component becomes disabled between it's checking for focus owner and actually transferring focus then focus ends up in limbo and the next component gets a focus gained but never a focus lost. Plus, I don't see it documented in the API at all.
Oh, and I will try to put together a compilable example though it most certainly won't be short.