Jerry Ye wrote:
However, it seems to me that if a JButton is pressed, if there's no other program calling CyclicBarrier, the whole GUI freezes, and even the JFrame can't be closed. How has this happened?
Henry Wong wrote:
Swing has a single thread to handle all events -- ie. the event dispatching thread.
Henry
Jerry Ye wrote:
If that's the case, how should I design my program to wait for the user's input?
Henry Wong wrote:
Why do you actually need to wait for input in a callback? Isn't that what the GUI is for? When a button is pressed, when text is entered, when the mouse moves, etc. etc. etc., you get an event for it. The GUI's job is to wait for input and report it to you as event callbacks.
Henry
Henry Wong wrote:
How are these two GUIs connected? Are they connected by a network? Or is it just one GUI (with 2 JFrames) handling two different users?
In the case of the network, you have to use a thread that is not the EDT. For example, you can create a task (that is to be run) for/by an executor. This task can do the external event, like wait for the other user's response. Upon completion, Swing also provides a way to register a callback to be called by the EDT, if needed. Or if the tasks after completion doesn't need to access Swing components, you can stay with the executor.
Henry
Campbell Ritchie wrote:Don't do anything strange with the Thread which Swing components run on, otherwise it will hang. Remember that GUI frameworks are usually not thread‑safe and can only be run from the one thread. If you start making things wait or anything like that on the Swing thread (called EDT=Event Dispatch Thread), you will interfere with painting of the GUI and it may stop responding
Tony Docherty wrote:You're creating two instances of the Board class and so you have two different CyclicBarriers each waiting for 2 threads.
Jerry Ye wrote:
I printed their hashcode. You are right. They aren't waiting for the same object. But how could this be possible? I've used this keyword and they are registered to two different instances?
Henry Wong wrote:
Not sure what the this keyword has anything to do with this...
Of course, isn't this all moot? You only have one EDT for all of swing, so, you don't have two threads for the barrier to release, even if you fix the barrier instantiation issue.
Henry wrote:Why do you actually need to wait for input in a callback? Isn't that what the GUI is for? When a button is pressed, when text is entered, when the mouse moves, etc. etc. etc., you get an event for it. The GUI's job is to wait for input and report it to you as event callbacks.
Jerry Ye wrote:
Well, I mean, if I initiated with the barrier of the JPanel that contains it, how can it call the await of the other JPanel? After all, they are two different instances, right?
Jerry Ye wrote:
Indeed, I has only one EDT, but I have also another thread I started myself in background, so it should work. And it indeed worked in another class that I've written. I think the problem is indeed the barrier instantiation issue.
Tony Docherty wrote:
May I suggest you forget about CyclicBarriers for now and answer Henry's much earlier post
Tony Docherty wrote:
May I suggest you forget about CyclicBarriers for now and answer Henry's much earlier post where he said:
Henry wrote:Why do you actually need to wait for input in a callback? Isn't that what the GUI is for? When a button is pressed, when text is entered, when the mouse moves, etc. etc. etc., you get an event for it. The GUI's job is to wait for input and report it to you as event callbacks.
How about creating the instance prior, and passing it as part of the construction process?
Campbell Ritchie wrote:I presume you know about Swing threading(←Java™ Tutorials section). That link tells you about background threads. You can monitor the background thread and show its progress with progress indicators.
Jerry Ye wrote:
How about creating the instance prior, and passing it as part of the construction process?
Well, I used static to solve it. I admit what I've written is a poor design, but I just want to know why it didn't work in the way I expected.
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime. |