JProgressBar
Hello. I am having trouble writing a JProgressBar for my applet. I tried using a PopupFactory to make a popup and put the JProgressBar in that, but the popup is in no way connected to the applet. When I move the applet the popup stays where it is, and depending on where the browser is, the popup may not even appear on the browser. Also, when I make a call to the method that is going to be doing the work (it will also be updating the JProgressBar) the JProgressBar just freezes and waits for the method to return, never even doing anything because when it returns, I have it reset the JProgressBar. Can someone please help me with these two problems? How can I get the Popup attached to the browser window, and how can I make the JProgressBar and the method both run simaltaneously?
> How can I get the
> Popup attached to the browser window,
I don't know. My guess is you can't, but I also don't know anything whatsoever about applets; hopefully someone will say that I'm wrong
> and how can I
> make the JProgressBar and the method both run
> simaltaneously?
If your task to monitor is running in the swing event dispatch thread (which I believe is the common cause of this behavior), then no repainting or updating or anything can happen until the long task is done. Try putting it in a separate thread. If that doesn't work, this comes up a lot, just do a search for JProgressBar
well, you don't know about JProgressBars and I don't know about threads. But that is what seems to be happening, its not being repainted I think...
haha, i said i didn't know about applets, not progress bars. i'm like the king of progress bars =p
Try running the task you're monitoring like this:
new Thread() {
public void run() {
// do stuff, update the progress bar
}
}.start();
So how many Threads can be running at the same time? And is there just one Thread for the main program if I don't make any Threads myself?
> the JProgressBar just freezes and waits for the method to return
Read:
http://java.sun.com/docs/books/tutorial/uiswing/components/progress.html
and
http://java.sun.com/docs/books/tutorial/uiswing/misc/threads.html
ProgressMonitor might be handy for your purpose instead of using Popup.
hiwaa at 2007-7-15 3:14:48 >
> So how many Threads can be running at the same time?
A lot, but there is some overhead for each, so you should avoiding using them unnecessarily. Actually moreso than the overhead, it can make you program sooo much more complicated than it needs to be if you use threads when you don't need them
> And is there just one Thread for the main program if
> I don't make any Threads myself?
If you don't use Swing or something like Timers, yes generally. Swing adds a few that you can read about in the second link from hiwa's post
The progress Monitor sounds like a better choice for me than a ProgressBar. Maybe that will solve the problem of my applet making everything wait until it returns from the task method or maybe not. I'll try it out.
1.) If I did use a thread, would I use it for my entire applet or should I just make it call the task method?
2.) Also, when you type thread.start() does it just run what is in the thread one time(if there is no while loop) or does it repeat itself until you call stop()?
3.) And would I have to write the entire method in the thread entirely (so that its not a method anymore?) or should I have the thread call the method?
> The progress Monitor sounds like a better choice for
> me than a ProgressBar. Maybe that will solve the
> problem of my applet making everything wait until it
> returns from the task method or maybe not. I'll try
> it out.
> 1.) If I did use a thread, would I use it for my
> entire applet or should I just make it call the task
> method?
A separate thread should do your 'the method that is going to be doing the work.' However, if
you should update GUI from within the thread, you have to wrap the GUI code with
SwingUtilities.invokeLater() method.
> 2.) Also, when you type thread.start() does it just
> run what is in the thread one time(if there is no
> while loop) or does it repeat itself until you call
> stop()?
Thread does its run() method. You should never call stop() method. When the run() returns,
it is the end of life of the thread.
> 3.) And would I have to write the entire method in
> the thread entirely (so that its not a method
> anymore?) or should I have the thread call the method?
It may depends on your taste. Remember invokeLater() method when you do a GUI work
from the thread.
hiwaa at 2007-7-15 3:14:48 >
cool. Yes, my work method updates the GUI I suppose, only because it updates the progress monitor. I don't know if the progress monitor will be considered part of the GUI though. I don't know about invokeLater(). I have read that it is a good idea to implement Runnable and stuff (dont know if that is the same thing), but nothing actually explains it for beginners so I don't get it. It sounds like using invokeLater() would be what I need to use if the progressMonitor isnt updating during the Thread Life. How does invokeLater work?
If your ProgressMonitor is pm,
// in your thread code
SwingUtilities.invokeLater(new Runnable(){
public void run(){
pm.setProgress(...);
pm.setNote(...);
}
});
hiwaa at 2007-7-15 3:14:48 >
The problem before, the reason the gui wasn't updating, was that you were performing a long task on the swing Event Dispatch Thread, so no painting could take place until the method was done. The idea is to perform your long task in a separate thread from the EDT, but the actual updates to ProgressMonitor should still be done on the EDT. That's the reason for invokeLater: you put the update in a Runnable, and it puts the Runnable on the EDT.
hmm.. so My task should be done in a thread,, but the update should not be part of the task? So if the task is done in a thread, then why would I need to put my code in a runnable? now what if I do something like this...
ActionListener timerListener = new ActionListener()
{
actionPerformed(ActionEvent e)
{
if(task == finished)
{
doTaskButton.setEnabled(false);
updateTimer.stop();
}
else
{
updateProgressMonitor();
}
}
};
Timer updateTimer = new Timer(1000, timerListener)
ActionListener doTaskButtonListener = new ActionListener()
{
actionPerformed(ActionEvent e)
{
doTaskButton.setEnabled(false);
start.updateTimer();
taskThread.start();
}
};
and then I run the task in its own thread... do I need to put all these listeners in a thread too? Or is the one thread for the task good enouph?
No. Kindofblue is a little bit confused.
You don't need to use timer here.
Just do it:
ActionListener doTaskButtonListener = new ActionListener(){
public void actionPerformed(ActionEvent e) {
doTaskButton.setEnabled(false);
start.myLongLongTaskThread();
}
};
//and in your myLongLongTaskThread:
// (pseudo code)
++amount;
if (amount % 500 == 0){
SwingUtilities.invokeLater(new Runnable(){
public void run(){
pm.setProgress(...);
pm.setNote("I'm so tired");
}
}):
}
hiwaa at 2007-7-15 3:14:48 >
I figured it out. I didnt use runnable at all. I just used Thread and ran the method from it. Apparently, I was typeing
Thread taskThread = new Thread()
{
public start()
{
while(true)
{
if(task should be done again)
{
call the task method
}
//set task should not be done again
}
};
I should have named the method run() and not start().. Plus...
I was using taskThread.stop() and making the task run and start() but stop() was deprecated which is why i had to use the while loop.
> No. Kindofblue is a little bit confused.> You don't need to use timer here.In what way am I confused? The Timer suggestion came from the link you posted. Please show me where I suggested anything other than the code snippet that you put here...
