aspose file tools*
The moose likes Swing / AWT / SWT and the fly likes Threads and mouse events Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Swing / AWT / SWT
Bookmark "Threads and mouse events" Watch "Threads and mouse events" New topic
Author

Threads and mouse events

J R Hatch
Greenhorn

Joined: Sep 07, 2011
Posts: 26
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

Joined: Jun 09, 2003
Posts: 4632
not sure I'm reading this right, but popping up a JOptionPane (to get your required input) might suit.
Paul Clapham
Bartender

Joined: Oct 14, 2005
Posts: 18135
    
    8

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

Joined: Oct 27, 2005
Posts: 19543
    
  16

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.


SCJP 1.4 - SCJP 6 - SCWCD 5 - OCEEJBD 6
How To Ask Questions How To Answer Questions
J R Hatch
Greenhorn

Joined: Sep 07, 2011
Posts: 26
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

Joined: Oct 27, 2005
Posts: 19543
    
  16

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

Joined: Sep 07, 2011
Posts: 26
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

Joined: Jun 09, 2003
Posts: 4632
> 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

Joined: Sep 07, 2011
Posts: 26
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.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Threads and mouse events
 
Similar Threads
Events and locking in thread
telling when a thread has ended, without waiting for it
Getting mouse events for a component in a Jtable cell
Getting the instance value at runtime.
Question about repainting