Tutorial on AWT/Swing control flow

Question

Greetings all,
Just wondering if any of you folks know of a good tutorial on AWT/Swing control flow? I'm doing some pretty complex stuff with a table whose editors call other windows and insert values into the table based on callback objects...weird stuff happening with loss of focus when the other windows come out, etc etc etc.
I have it working via a series of what I consider kludges, but I would really like to implement it cleanly, and it's looking like that's going to require understanding <ugh> <grin>
So it looks like it's time that I bit the bullet and got to grips with control flow in AWT/Swing. Is there a tutorial out there that could help me with this?
Many TIA

Answer 1

skiaddict1 wrote:
Let's take your word for it, but if you have the slightest doubt please consider the subject: EDT violation is a classic here.OK sure, but I really don't think I'm violating it. I avoid multi-threading like the plague, and only introduced it for my report writer because I wanted to have a little window advising the user that the report was in the process of being written.Raise your left hand and swear this report writer is not running when you experience the problem you describe! >o(
OK, this is just kidding, as per the rest of your description, it sounds reasonable now to assume that your problem is not related to EDT violation.
I'm doing some pretty complex stuff with a table whose editors call other windows and insert values into the table based on callback objects...This summary is a bit worrying, and I thought you would mention problems in the display of the table being edited. But you seem to refer to problems in other windows, or did I misunderstand?
Or do you mean, loss of focus in the editor still being edited? Can you please clarify what you do and what your problems are?
In particular, what does the other windows come out mean?OK, I was trying to be sparse with details because I didn't think they were relevant.Actually the worrying seems all the more justified, now that you have described it more extensively: I was afraid that you would raise other windows while editing, and that's the case. I know little of focus though...
I have a table in window A, one of whose columns has a custom editor which, when a cell in the column is double-clicked, registers itself with window B as a choice-listener (see later) then asks window B to come to the front. Window B, when the user performs a choice amongst the UI elements in there, fires a choice-event to its listener, i.e. the custom editor. At which point the editor saves away the chosen value (for use by getCellEditorValue()), sets the text in the cell appropriately, turns edit mode off via fireEditStopped(), and brings window A back to the front.
(...) once the custom editor asks window B to come to the front, the table in window A loses focus and when it is brought back to the front, the table's JScrollPane seems to have the focus (visually, it has the focus rectangle around it). Pressing the Tab key has no effect on focus; you have to use the mouse to focus something.I assume you have read the tutorial on using tables in Swing.
It contains an example where a custom editor is bringing up a dialog: http://download.oracle.com/javase/tutorial/uiswing/components/table.html#editor
AFAIK, the example does not suffer from focus problems.
What I am finding, and I reiterate this is new since I rewrote the windowing subsystem for the app (the custom editor was not changed in the rewrite), is that (...)Just what do you call "rewriting the windowing system" (just to rule out the possibility of something Ramboesque)?
I have no idea why this loss of focus is occurring, and I am at a loss to begin to figure it out. As I wrote above, I have a series of kludges which gets around the symptoms, but I would really rather figure it out and fix it.OK I admit I cannot tell what happens exactly, but:
1) instead of bringing window B to front, couldn't the editor bring up a dialog B (e.g. using JOptionPane.showXxxDialog() to bring up just the choice panel? The advantage is that it is more "synchronous", you can control when the window A's table model is updated.
2) what worries me too is that you update the model of the table being edited while you're editing one cell of it? Would it be possible, and make sense in your case, to update this model later (that is, post the model update as an invokeLater(...) call)? I don't see how seeing the table updating underneath helps the user editing its cell, but you may have your reasons.
What do you call flow control , or control flow in AWT/Swing?Basically, what I am after is something that will help me begin to understand/diagnose problems such as the above when they happen in my code. I am deeply averse to multi-threading (...) Things in my code were working, and that was enough for me.
But the above behaviour, and another weird behaviour I was having last week, which again I have solved with what I consider a kludge, and again which only began with my new windowing subsystem, have caused me to realise that it's time I really got to grips with this issue.Yes, when they say beware of threads when using Swing , nobody tells to not use threads! Just to be aware of how special Swing is with regards to threads (at least, compared to AWT, that didn't make such warning).
I would like, for example, to really deep-down understand exactly when listeners for AWT-Swing events get called. I don't really care so much when the events get put on the queue, but I do care when exactly my event handlers will be called. This will help me diagnose problems, I'm sure.Well they get called in the EDT, by some framework code that, in an infinite loop, does something along the lines of:
- pop next event from the event queue
- determine which is the target widget
- let the widget transform the event and send it to all registered listeners
Now with dialogs, things gets dimmer, because while a dialog is brought up (via a<tt>setVisible(true)</TT> call on the EDT, the EDT is indeed suspended, and a new event thread manages the events for the dialog).
I'm sorry I have no reference for that behavior, and my description is certainly blurry (and possibly wrong), but I don't think your problem is so much related to threading as I initially thought.
N.B.: Darryl's second link does features sequence diagrams that try to demonstrate what happen (in a specific example with asynchronous access, but you can derive the simpler, regular, working, from it).OK, yes I saw that diagram, I was offput by the asynchronicity but I will have another look tomorrow also. Thanks againDon't put too much hopes in there, indeed it's definitely not the kind of info I understand you're looking after.
Much luck all the same, and feel free to come back with your findings, or with more questions, about the initial subject (reference on event flow) and the specific problem (your focus issues with the editor).
I also cannot end this message without suggesting that you try to reproduce the problem with an SSCCE (http://sscce.org), that you could post here for us to try out. See this recent discussion about the multiple interests of this approach: {message:id=9587964}
Best regards,
J.