views:

45

answers:

4

Hello everyone, I have a GUI problem that I would like to get sorted out, but I am baffled as to what's happening and hope one of you can explain it. The code base is way too large to upload however I will explain in detail what's happening:

I have a class ProgessBar which is a JDialog containing a swing JProgressBar. I have some getters and setters to change the bar to my liking however here comes the issue.

The ProgressBar is spawned inside of a method myButtonActionPerformed

myButton.addActionListener(new java.awt.event.ActionListener() {
            public void actionPerformed(java.awt.event.ActionEvent evt) {
                myButtonActionPerformed(evt);
            }
        });

essentially when the user hits this button, the processing begins and the ProgressBar is spawned.

The user currently has a JFrame in front of them and this progress bar is popped up in a JDialog. After stepping through debug mode in Netbeans, I can see the JProgressBar's values getting changed, but the bar visually stays at 0% while my program is processing then instantly jumps to 100% the moment it leaves the add action listener method above, almost as if it was waiting to repaint until out of that listener. What am I not understanding? Is there something I can call that will force it to update inside of this myButtonActionPerformed method instead of waiting until it's useless.

A: 

I can't comment yet due to lack of rep. Until then, you need to post more code about what you're doing with the progressbar. I can only point you to the Sun Tutorial on them for now.

Anon
There is an enormous amount of code to the point where it's unreasonable to go through and copy out the relevant sections. If the structure of the code is unclear, please ask a detailed question and I will clarify.
Ryan
A: 

The reason it doesn't update is because your UI thread is busy in the ActionPerformed listener doing processing. If you try and interact with your application, you'll notice that nothing on the UI is responsive.

The solution to this is to not do processing on the UI thread - launch another thread, do the processing on that, and call back to the UI thread to update the progress bar.

Anon.
+2  A: 

Are you doing whatever takes that time in the EDT? Keep in mind that AWT/Swing have a dedicated thread that does GUI work – handling event handlers, repainting the GUI, etc. If you do long-running things on that thread, Swing will not repaint.

Try performing your task in another thread and update the progressbar from there accordingly. Use SwingUtilities.invokeLater or invokeAndWait to update the progressbar, though, to ensure that the GUI updates happen on the EDT. Otherwise things get very weird.

Joey
Thank you very much, this sounds very reasonable. I looked up some things you had given me and found this link to be useful for anyone else looking through this forum thread in the future: http://java.sun.com/developer/technicalArticles/javase/swingworker/#EDT
Ryan
@Ryan: Yes, I should have mentioned `SwingWorker`. Apologies. And yes, I guess that link leads you in the right direction here.
Joey
A: 

First your anonymous ActionListener simply forwards to a method called myButtonActionPerformed, so obviously the issue is not in the posted code, but rather in something that happens or is caused to happen inside myButtonActionPerformed. So that would be the relevant code to post (if possible).

Second other people probably nailed this already because the likely thing is indeed heavy processing on the EDT. One can use SwingWorkers to efficiently route the progress/status updates to the GUI thread as appropriate and also move the background processing off the EDT.

Third: out of interest, do you happen to use NetBeans for your GUI design? Looks like its automatically generated code, to me.

Yes, I use netbeans for the design as well.
Ryan