Hey! I am having a problem with threads in applets. So I launch my applet. When the user clicks a button, then code is run, and ultimately I want to wait until the user clicks another button. So essentially, I've want a wait in one button handler, and a notify in another. No matter what I try this doesn't seem to work. Basically, no matter how I try to do it, the whole applet seems to lock up when I get to the wait. I've tried anonymous inner classes, separate action listener classes, and having the applet itself handle the events. I've tried wait/notify, I've tried sleeping in a loop and then testing a flag, and I've tried using locks. Nothing seems to work, and the behavior always seems to be that the applet locks up. Any help would be appreciated. A fragment of code would be nice, because I think there is something fundamental I am missing. I've got several books here and have tried a variety of things, but they never seem to work.
All GUI events are handled on one thread. If you wait() in a button press handler, then the GUI can't respond to any more button presses. Event handlers should always return ASAP, and they can never do anything that would involve waiting for more events. Therefore it's obvious why anything you've tried so far would be doomed to fail. I don't know what your code does exactly, but I'll imagine that when you press one button, it does a long calculation, and when that calculation completes, it enables a button, and then the user has to press that button before the results are presented. The trick, then, is that you want to do the long calculation, the second-button-enabling, and the wait() in a new thread that you spawn yourself. You can do the notify() from the regular event handling thread. Pseudocode (real code would imply I had to dot all the i's
Make sense? displayResults() should use SwingUtilities.invokeLater() to do any GUI updates (technically I believe I should have used it to call setEnabled(true) although you can generally get away without it.) [ August 07, 2003: Message edited by: Ernest Friedman-Hill ]
Gak. I introduced the separate lock as a safety measure after I had typed most of the code -- I left half of it unconverted. I'm going to go and edit my original post -- wait a few minutes and then look at it again.
I am really grateful for your help. That works with no exceptions, but there is some incredibly strange behavior! First of all, it registers button clicks, but V-E-R-Y slowly. Also, every button click registers TWICE!!! If you have a spare moment, could you see what I'm doing wrong? It must be very simple, but for the life of me, I can't figure out how it could be registering two button clicks!
Well, I can't help you with the "double click" thing, because I don't see anything here that would cause this problem (because I couldn't see anything, I actually compiled and ran your code, and I didn't observe the problem.) But I can help with the speed issue. I'm not sure where you got the idea to call repaint() inside paint(), but what repaint() does is tell the JVM to call paint() from another thread; so because of this call, paint() is being called in an endless loop, accomplishing precisely nothing except for eating up lots of CPU cycles. If you implement paint (and you don't need to here, at all) what you do is call things like Graphics.drawLine(), etc, to draw pictures; then the JVM normally takes care of calling paint() whenever the window needs updating.
Thanks so much. I have no idea why that repaint() was in there! When I took it out, you're right, it fixed the time issue, AND it fixed the double click issue. Bizaree! Thanks a million for the help. With respect, Matt