Java Question: Making the program wait for a button event

[flashbacck]

At one point in my program, it waits for the user to press a button. At this point, my code is:

do{
Thread.sleep(200);
}while (x <-2);

x is changed to > -2 when one of the buttons is pressed. The Thread.sleep(200) is to keep processor usage from going to 100%.

It works, but it seems like a stupid way to do it. What's the usual way to have my program sit patiently until the user presses a button?

Thanks.

 

[tfinch2]

Uhh, you need ActionListeners buddy.

http://java.sun.com/docs/books/tutorial/uiswing/events/actionlistener.html

 

[kamper]

If you're talking about blocking a background thread until a button is pressed, pick some object, call wait() on it and then call notify() on it from the event thread when the button is clicked.

There are a variety of fancier techniques like blocking queues and mutexes and semaphores in java.util.concurrent if you need something more sophistocated.

 

[tfinch2]

Originally posted by: kamper
If you're talking about blocking a background thread until a button is pressed, pick some object, call wait() on it and then call notify() on it from the event thread when the button is clicked.

There are a variety of fancier techniques like blocking queues and mutexes and semaphores in java.util.concurrent if you need something more sophistocated.

I don't think he's referring to thread syncronization.

 

[kamper]

Originally posted by: tfinch2

Originally posted by: kamper
If you're talking about blocking a background thread until a button is pressed, pick some object, call wait() on it and then call notify() on it from the event thread when the button is clicked.

There are a variety of fancier techniques like blocking queues and mutexes and semaphores in java.util.concurrent if you need something more sophistocated.

I don't think he's referring to thread syncronization.

He must be, or his above example wouldn't work. If the event thread were in a continuous loop like that, the button press would never fire and the condition would never change.

 

[flashbacck]

yes, I am using actionlisteners for the buttons. How else do you think I'm getting the buttons to change x?

pseudo code is:

{
x = -2;
enable all buttons

my above Thread.sleep code

disable all buttons
return x;
}

 

[tfinch2]

Originally posted by: kamper

Originally posted by: tfinch2

Originally posted by: kamper
If you're talking about blocking a background thread until a button is pressed, pick some object, call wait() on it and then call notify() on it from the event thread when the button is clicked.

There are a variety of fancier techniques like blocking queues and mutexes and semaphores in java.util.concurrent if you need something more sophistocated.

I don't think he's referring to thread syncronization.

He must be, or his above example wouldn't work. If the event thread were in a continuous loop like that, the button press would never fire and the condition would never change.

Maybe you're right, need more code or more explaination to determine.

 

[tfinch2]

Originally posted by: flashbacck
yes, I am using actionlisteners for the buttons. How else do you think I'm getting the buttons to change x?

pseudo code is:

{
x = -2;
enable all buttons

my above Thread.sleep code

disable all buttons
return x;
}

Use wait and notify as kamper suggested. Monitors in java are easy!

http://www.jchq.net/tutorial/07_03Tut.htm

 

[flashbacck]

I'm not sure wait()/notify() is what I want... I'm not doing any multiple threads.

Basically my main program calls a method that returns an int. I wanted a way to manually input an int for debugging purposes, so I wrote this class. I also wanted to mess around with Swing, otherwise I'd do this with System.in.

more pseudocode:

 

[flashbacck]

evening bump

 

[kamper]

How are you starting the gui stuff? Can you please post that code?

And yes, you almost certainly are using multiple threads and you're doing it in a somewhat unsafe way as well. Swing will start more threads (or at least one anyway) when you start a gui. At least try wait() and notify().

 

[flashbacck]

sure. I'm not sure I understand how to use wait and notify, though. Below is makegui() which is called in the constructor.

 

[kamper]

I think it's fine to use the ManualEntry instance itself. Replace your entire wait loop with this.wait() and add a this.notify() to both action listeners. It should go before changing the value of x.

If that acts funny, replace this with some other object. I'd just declare a private final Object in ManualEntry for just that purpose. That has the added advantage of preventing any other code from calling notify(), unlikely as that is for your ManualEntry instance.

 

[flashbacck]

Using either this.wait() or dummyobj.wait(), I get the following error:

java.lang.IllegalMonitorStateException: current thread not owner
at java.lang.Object.wait(Native Method)
at java.lang.Object.wait(Unknown Source)

 

[kamper]

Sorry. Either put a synchronized(this) { ... } block around the wait() call or declare the action() method as synchronized. If you use dummyobj, you have to use a synchronized (dummyobj) { ... } block. It'd be a good idea to read the javadocs for wait() and notify(). I think using the dummyobj is also the best idea, just for encapsulation's sake.

 

[kamper]

This is a little too complicated for a simple blocking dialogue. Have you looked at JOptionPane? I'd be willing to bet you can pull this off without any threading work on your part.

 

[flashbacck]

cool! I had to synchronize both the wait and the notify's. Thanks for the help.

edit: I had to put the notify statements after modifying x. Otherwise action() wakes up and proceeds before x is changed.

 

[IHateMyJob2004]

Originally posted by: kamper
This is a little too complicated for a simple blocking dialogue. Have you looked at JOptionPane? I'd be willing to bet you can pull this off without any threading work on your part.

I was stating to think the same thing.

It seems like alot of work is being done when the solution is probably trivial if attacked from a different viewpoint. Regardless .... without seeing ALL the code and nowing what is going on .... it's kind of a moot point at this time.

 

[flashbacck]

Originally posted by: IHateMyJob2004
I was stating to think the same thing.

It seems like alot of work is being done when the solution is probably trivial if attacked from a different viewpoint. Regardless .... without seeing ALL the code and nowing what is going on .... it's kind of a moot point at this time.

well what I've shown already is basically the entire class. Not sure what else you want to see.

 

[kamper]

Originally posted by: flashbacck
I had to put the notify statements after modifying x. Otherwise action() wakes up and proceeds before x is changed.

Whoops, stupid mistake on my part. This is why it's better to use a toolkit that's taken care of all the little things for you already, but as long as working now...