> Hi.
> I have an swt app and I'm working in eclipse.
[quoted text clipped - 11 lines]
> couple of file dialogs to get input and output file names, and then
> reads one file and writes the other.
<snip>
>If possible, always post complete code that can be run. It doesn't help
>to snip some methods... (If your code base in huge, see if you can
>extract a code sample that is runnable in its own right, and that
>demonstrates the problem or question.)
Sure. I thought it was enough to demonstrate, but it sure would not build I
know.
>As a general point, your code is very procedural in style (i.e. sticking
>loads of stuff into the main method). I presume you've not done much OO
[quoted text clipped - 5 lines]
>onto more advanced things like threading, GUIs, etc. Get comfortable
>with walking before you start running and all that....
I actually have a large amount of processing in the processingToDo method,
broken up into 3 or 4 classes.
>A more conventional OO way to do things is to separate your concerns
>into independent parts (classes). One clear concern of your program is
>the act of copying the file.
My fault. I copied some base code from a copyFile example as it read and wrote
files, which was the basic thing I was trying to do. It isn't really copying
the file, but reading the drWatson log and picking information out as it goes
along, writing summaries to another file.
> Another concern is the reporting back of
>the progress to the user in a dialog. Keep these concerns separate by
[quoted text clipped - 10 lines]
>
>Try googling!
Actually I did (google), and I just got a bit confused as to the generally
accepted best way - you know putting the thread/dialog thing all together and
retrofitting it into my app. I figured the processing should move into its own
thread, and then a progress dialog should get displayed, but also allow
communication with the main thread in case it decides to terminate. I'll study
the google results more.
>[[Some more advanced design concepts for later on: be aware that you
>reduce the coupling between the copier class and the progress dialog
[quoted text clipped - 4 lines]
>(e.g. by programming to an ProgressListener interface that you create,
>or similar).]]
Thanks. This sounds pretty reasonable. I'm always looking for examples because
there isn't ever enough time (I'm pounding this at home though I need it at
work), and I'd really rather be pushing my son on the swing... ;> )
Thanks for your advice.
Jeff
Jeff Kish
Nigel Wade - 11 Apr 2006 09:48 GMT
> Actually I did (google), and I just got a bit confused as to the generally
> accepted best way - you know putting the thread/dialog thing all together and
> retrofitting it into my app. I figured the processing should move into its own
> thread, and then a progress dialog should get displayed, but also allow
> communication with the main thread in case it decides to terminate. I'll study
> the google results more.
This may help as a starting point:
http://java.sun.com/docs/books/tutorial/uiswing/components/progress.html
it outlines some of the common problems, solutions, gotchas etc.
Also, essential reading before using threads in Swing is this section:
http://java.sun.com/docs/books/tutorial/uiswing/misc/threads.html
Progress bars are very simple in concept, but quite difficult to realize.

Signature
Nigel Wade, System Administrator, Space Plasma Physics Group,
University of Leicester, Leicester, LE1 7RH, UK
E-mail : nmw@ion.le.ac.uk
Phone : +44 (0)116 2523548, Fax : +44 (0)116 2523555
Jeff Kish - 11 Apr 2006 13:18 GMT
>> Actually I did (google), and I just got a bit confused as to the generally
>> accepted best way - you know putting the thread/dialog thing all together and
[quoted text clipped - 5 lines]
>This may help as a starting point:
>http://java.sun.com/docs/books/tutorial/uiswing/components/progress.html
Thanks very much.
>it outlines some of the common problems, solutions, gotchas etc.
>
>Also, essential reading before using threads in Swing is this section:
>http://java.sun.com/docs/books/tutorial/uiswing/misc/threads.html
Does it matter I'm using SWT instead of Swing?
>Progress bars are very simple in concept, but quite difficult to realize.
I think I can get along with a progress indicator instead of a progress bar,
i.e. a changing textual indication of where the processing is at rather than a
bar that creeps along from point a to point b. I wonder if that makes it any
easier or not...
Jeff Kish
Nigel Wade - 12 Apr 2006 09:45 GMT
>>> Actually I did (google), and I just got a bit confused as to the generally
>>> accepted best way - you know putting the thread/dialog thing all together and
[quoted text clipped - 12 lines]
>>http://java.sun.com/docs/books/tutorial/uiswing/misc/threads.html
> Does it matter I'm using SWT instead of Swing?
Sorry, I missed that point.
I'm afraid I don't know, I've not used SWT . I don't even know if the
multi-threading issues are the same.

Signature
Nigel Wade, System Administrator, Space Plasma Physics Group,
University of Leicester, Leicester, LE1 7RH, UK
E-mail : nmw@ion.le.ac.uk
Phone : +44 (0)116 2523548, Fax : +44 (0)116 2523555