Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > Do I need Threads for this?

Reply
Thread Tools

Do I need Threads for this?

 
 
Guest
Posts: n/a
 
      12-05-2006
I've got a method that copies files from one place to another. Each time the
file copies over it takes roughly 10 seconds per file (depending on how
large the file is).

In the meantime, I need my JPanel label to update with the current number of
files copied over so far.

I know from looking at the FAQs for this newsgroup that the GUI isn't
updating because it probably needs a new thread, but as a complete newbie to
threads, I'm wondering if I really need to learn about Threads to get my
relatively simple job done. My code simply runs in a for loop -

int count=0;

for (int i=0; i < 12; i++) {

mycopyOverFileMethod();
count++;
label.setText("Files Copied:" + count);

// Why is there no simple way in java just to put here something like :
// label.redraw();
// that avoids the need for threads??

}

Is there something simple I could do?

TIA


 
Reply With Quote
 
 
 
 
DRS.Usenet@sengsational.com
Guest
Posts: n/a
 
      12-05-2006
http://www.velocityreviews.com/forums/(E-Mail Removed)lid wrote:
> I've got a method that copies files from one place to another. Each time the
> file copies over it takes roughly 10 seconds per file (depending on how
> large the file is).
>
> In the meantime, I need my JPanel label to update with the current number of
> files copied over so far.


Yes, you need threads, but it's not that hard. You make a class that
implements Runnable or extends Thread. Then you can do all ten files
at once, if you choose to!

--Dale--

 
Reply With Quote
 
 
 
 
Oliver Wong
Guest
Posts: n/a
 
      12-05-2006

<(E-Mail Removed)> wrote in message
news:(E-Mail Removed) ups.com...
> (E-Mail Removed)lid wrote:
>> I've got a method that copies files from one place to another. Each time
>> the
>> file copies over it takes roughly 10 seconds per file (depending on how
>> large the file is).
>>
>> In the meantime, I need my JPanel label to update with the current number
>> of
>> files copied over so far.

>
> Yes, you need threads, but it's not that hard. You make a class that
> implements Runnable or extends Thread. Then you can do all ten files
> at once, if you choose to!


It's not super hard, but it's not super easy either. This tutorial
should get you started:
http://java.sun.com/docs/books/tutor...l/concurrency/

- Oliver


 
Reply With Quote
 
Guest
Posts: n/a
 
      12-05-2006
> Yes, you need threads, but it's not that hard. You make a class that
> implements Runnable or extends Thread. Then you can do all ten files
> at once, if you choose to!


Hmm, seems a bit awkward, but then Java seems that way sometimes...

Methodically, I can't understand how by splitting the work into two threads
its going to update the label at the time I need it to - won't it just split
into two and one process copy over the files in one thread all at once and
update the labels all at once in the other, meaning that there won't be any
real live interaction between the two? I guess I'm really saying that I
don't understand how the thread processes interact with each other...


 
Reply With Quote
 
Oliver Wong
Guest
Posts: n/a
 
      12-05-2006

<(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
>> Yes, you need threads, but it's not that hard. You make a class that
>> implements Runnable or extends Thread. Then you can do all ten files
>> at once, if you choose to!

>
> Hmm, seems a bit awkward, but then Java seems that way sometimes...
>
> Methodically, I can't understand how by splitting the work into two
> threads its going to update the label at the time I need it to - won't it
> just split into two and one process copy over the files in one thread all
> at once and update the labels all at once in the other, meaning that there
> won't be any real live interaction between the two? I guess I'm really
> saying that I don't understand how the thread processes interact with each
> other...


Presumably the thread which is doing the file-copying will update some
region in memory, recording it's progress. E.g. "Okay, I'm done with file
#4... now I'm done with #5... #6...", periodically releasing the CPU
(actually, once it tells the HD to start copying, it can immediately release
the CPU, because it has to wait for the HD to actually perform the reads and
the writes, only to be notified when the copy has finished, to schedule more
copies, and go back to sleep).

Meanwhile, the main thread will be scanning this region of memory and
see "Okay, so that thread is done with file #6. That means I need to change
the label to say 'Files copied: 6', and then release the CPU so that the
implicit thread that AWT/Swing creates has a chance to actually draw the
changes I've made to screen."

- Oliver


 
Reply With Quote
 
Guest
Posts: n/a
 
      12-05-2006
> Presumably the thread which is doing the file-copying will update some
> region in memory, recording it's progress. E.g. "Okay, I'm done with file
> #4... now I'm done with #5... #6...", periodically releasing the CPU


Well yes - as in my original code -

mycopyOverFileMethod();
count++;
label.setText("Files Copied:" + count);

- this copies the file, when that's done, surely, the thread continues onto
count++ (recording in memory where its got to) and then sets the label.

Why does my label not update before going back around in the for loop to do
another file copy? Surely the processor is freed up to do the lines after
the mycopyOverFileMethod() before doing this method again? That's why I'm
confused!


 
Reply With Quote
 
Colin Miller
Guest
Posts: n/a
 
      12-05-2006
Try calling label.repaint(); after you set the text. Or if you're using
say a JFrame, try calling the JFrame's repaint(); method.

It's possible that even though you updated the component, it was never
painted to the screen.

~Colin

(E-Mail Removed)lid wrote:
> > Presumably the thread which is doing the file-copying will update some
> > region in memory, recording it's progress. E.g. "Okay, I'm done with file
> > #4... now I'm done with #5... #6...", periodically releasing the CPU

>
> Well yes - as in my original code -
>
> mycopyOverFileMethod();
> count++;
> label.setText("Files Copied:" + count);
>
> - this copies the file, when that's done, surely, the thread continues onto
> count++ (recording in memory where its got to) and then sets the label.
>
> Why does my label not update before going back around in the for loop to do
> another file copy? Surely the processor is freed up to do the lines after
> the mycopyOverFileMethod() before doing this method again? That's why I'm
> confused!


 
Reply With Quote
 
Guest
Posts: n/a
 
      12-05-2006
> Try calling label.repaint(); after you set the text. Or if you're using
> say a JFrame, try calling the JFrame's repaint(); method.
>
> It's possible that even though you updated the component, it was never
> painted to the screen.


Thanks for the suggestions - I'd already tried that - it just doesn't update
until the for loop gets to the end then it updates the label and obviously
not as intended (ie only updates it with the finishing number rather than
updating it with the current number as it goes along)

: (


 
Reply With Quote
 
Colin Miller
Guest
Posts: n/a
 
      12-05-2006
Ok, how about this. Create a new class of type Runnable (You'll need
to read up a bit on threading on this, and it's good to know anyway).
Inside of that class is where you will do your file copying. Also in
that class, have a variable to store whatever class holds your JPanel.
When creating an instance of this new class, pass it a reference to
that class for callback.

In your main class, or wherever you initiate the file copying, create
an instance of this new class and pass it "this" and set it to run. In
the class that does the file copying, after you finish copying a file,
you'll call a callback method to do the form update. Unfortunately, I'm
bad at explaining it.. I'll put some psudocode for you.

//Main Class
//Note: This will probably look different

public class MainClass {
public static void main(String[] args) {
JFrame = new JFrame();
/* ... all your other components and whatever you do to set your
screen */
}

public void buttonClick(Event e) {
//I'll assume you start file copying on a button click or something
FileCopying fc = new FileCopying();
fc.setCallback(this);
new Thread(fc).start();
}

public void updateCopies(int copies) {
label.setText("Files copied: " + copies);
}
}

//FileCopying class
public class FileCopying implements Runnable {
private MainClass callback;
/* whatever else you need for copying */

public void setCallback(MainClass cb) {
callback = cb;
}

public void run() {
for (int i=0; i < filesToBeCopied; i++) {
/* do your file copying here */
callback.updateCopies(i);
}
}
}


I hope that made some sense.. been a while since I did graphical work
and threads and all of that, but should help with some ideas hopefully.

~Colin


(E-Mail Removed)lid wrote:
> > Try calling label.repaint(); after you set the text. Or if you're using
> > say a JFrame, try calling the JFrame's repaint(); method.
> >
> > It's possible that even though you updated the component, it was never
> > painted to the screen.

>
> Thanks for the suggestions - I'd already tried that - it just doesn't update
> until the for loop gets to the end then it updates the label and obviously
> not as intended (ie only updates it with the finishing number rather than
> updating it with the current number as it goes along)
>
> : (


 
Reply With Quote
 
DRS.Usenet@sengsational.com
Guest
Posts: n/a
 
      12-05-2006

Oliver Wong wrote:
> <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
> >> Yes, you need threads, but it's not that hard. You make a class that
> >> implements Runnable or extends Thread. Then you can do all ten files
> >> at once, if you choose to!

> >
> > Hmm, seems a bit awkward, but then Java seems that way sometimes...
> >

snip
> > saying that I don't understand how the thread processes interact with each
> > other...

>
> Presumably the thread which is doing the file-copying will update some
> region in memory, recording it's progress.


Yeah, sorta, but when I think about doing things in Java, I try not to
think of memory regions. The idea has already been expressed above:
You pass a reference of "yourself" (ie "this") to the thread doing the
copy. Then you can do lots of stuff, like call a method in "yourself"
from the spun-off thread. And/or you can use "join" that waits for all
of your threads to complete. I didn't look at that example link, but I
imagine that would be a really good way to start (that is, unless
someone more energetic than I writes you a snippet or two... it really
wouldn't be many lines of code... like 15 maybe).

--Dale--

--Dale--

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Java Threads - Get running threads Pedro Pinto Java 2 04-08-2008 11:44 PM
[new to threads] threads with UI and loop Une bévue Ruby 0 06-14-2006 10:22 AM
TB View, Threads, Threads with unread The Invisible Man Firefox 1 03-20-2006 02:09 AM
Standard Threads vs Weightless Threads yoda Python 2 08-01-2005 09:12 PM
threads without threads sindica@gmail.com C Programming 4 08-27-2004 09:25 PM



Advertisments