• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Threads and mouse events

 
J R Hatch
Greenhorn
Posts: 26
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
So, I know this doesn't work, but what I want to do seems to be what would intuitively seem to happen if you set a boolean variable "waiting" to true in the code for one button's event handler on a panel, then followed that (still in the event handling code) with



and in a separate, unrelated, mouseInputAdapter's handling code you told it to do something and then set waiting=false.

Basically, while running through a block of code as the result of a button press, I want to pause it and wait for mouse input. Is there a simpler way to do this than put that code in a separate thread?
 
Michael Dunn
Ranch Hand
Posts: 4632
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
not sure I'm reading this right, but popping up a JOptionPane (to get your required input) might suit.
 
Paul Clapham
Sheriff
Pie
Posts: 20971
31
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Your event-handling code shouldn't be waiting for other events. You'll just make the UI stop responding if you do that. (Although the JOptionPane would make that not matter, it's true.) So chances are that isn't really what you want to do. Could you explain why you think you need to wait for the mouse to do something?
 
Rob Spoor
Sheriff
Pie
Posts: 20512
54
Chrome Eclipse IDE Java Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Button event handlers are called from the Event Dispatcher Thread (EDT). So are mouse event handlers. As a result, the waiting code and code that would stop the waiting will run in the same thread. That leaves two possibilities:
1) the stopping code runs first and there's no waiting at all.
2) the waiting code runs first and you wait forever.

So no, this is not a good idea.

What kind of mouse interaction were you talking about? If it's clicking OK on some dialog then JOptionPane is indeed an option. When modal dialogs are shown this will block the current method until the dialog is hidden, but it does not freeze up the EDT.

If it's a different kind of mouse event you should probably use a SwingWorker. Let the button kick off the SwingWorker, which will execute its doInBackground method in a different thread. Note that you will need to use publish / process or EventQueue.invokeLater / EventQueue.invokeAndWait to do any querying or updating of the user interface. And your waiting variable would need to be volatile if it's used in multiple threads or you risk its value being cached, therefore again hanging your code since any updates aren't seen.
 
J R Hatch
Greenhorn
Posts: 26
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks for y'all's responses.

I'm writing a game (to teach myself Java) and at one point, a player needs to choose one from a collection of tiles which must be drawn, and I guess I was thinking JOptionPane.showInputDialog wouldn't lay it out right.
 
Rob Spoor
Sheriff
Pie
Posts: 20512
54
Chrome Eclipse IDE Java Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You can use JOptionPane.showConfirmDialog with your own component (JPanel, JList, whatever) as the message. If the result is OK / Yes / ... then you can retrieve the data from that component.
 
J R Hatch
Greenhorn
Posts: 26
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Rob Spoor wrote:You can use JOptionPane.showConfirmDialog with your own component (JPanel, JList, whatever) as the message. If the result is OK / Yes / ... then you can retrieve the data from that component.


Actually, I needed to get one of several options, so I created a modal JDialog and had it modify a field from its parent. That worked, though I have a question about the dialog I created that I will put in a different thread.

But for another part, I have a board already drawn on the screen and the players all need to pick starting positions. So, in response to the Start Button, I need to get all the starting positions and (once they're all chosen) begin the normal running of the game. The only way I could think to do it was start a thread for the startgame stuff, pause it while waiting for a mouse click, then finish the thread. Is there a more efficient way?
 
Michael Dunn
Ranch Hand
Posts: 4632
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
> The only way I could think to do it was start a thread for the startgame stuff, pause it while waiting for a mouse click, then finish the thread.

think of the many programs you have installed.

do they just install, or do you have to select/confirm options (perhaps agree to stuff before 'next' is highlighted/available).

i.e. get all your 'startgame' stuff prior to the game starting
 
J R Hatch
Greenhorn
Posts: 26
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Michael Dunn wrote:> The only way I could think to do it was start a thread for the startgame stuff, pause it while waiting for a mouse click, then finish the thread.

think of the many programs you have installed.

do they just install, or do you have to select/confirm options (perhaps agree to stuff before 'next' is highlighted/available).

i.e. get all your 'startgame' stuff prior to the game starting


Well, yeah, but the player should see his or her hand of cards before picking a starting position, so it has to be after the cards are dealt, then etc.


Anyway, I guess the thread is the best way to do it. It works, at least.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic