«

Hi.
I have an swt app and I'm working in eclipse.

I'm trying to figure out the best way to fit a status dialog up that
will allow me to report records processed etc and make cancel /pause
processing buttons available.

I'm pretty rust so a pointer to a code snippet or actual code would be
appreciated.
Thanks
Jeff

p.s. here is my main. basically the'processingToDo' method puts up a
couple of file dialogs to get input and output file names, and then
reads one file and writes the other.

public class HelloWorld {




public static void main(String[] args) {
boolean firstTime = true;
String fileToProcess = new String();
String outputFile = new String();
LogFileProcessor theLFP = null;
Display display = new Display ();
Shell shell = new Shell (display);
Label label = new Label (shell, SWT.CENTER);
label.setText ("Hello_world");
label.setBounds (shell.getClientArea ());
shell.open ();
theLFP = new LogFileProcessor(shell);
while (!shell.isDisposed ())
{
if (firstTime)
{
firstTime = false;
}
else
{
// The file already exists; asks for
confirmation
MessageBox mb = new MessageBox(shell,
SWT.ICON_WARNING
| SWT.YES | SWT.NO);

// We really should read this string from a
// resource bundle
mb.setMessage("Process Another? ");

// If they click Yes, we're done and we drop
out. If
// they click No, we redisplay the File
Dialog
if (mb.open() != SWT.YES)
{
break;
}
}
fileToProcess = theLFP.ProcessingToDo();
if (fileToProcess != null)
{
label.setText("input file: " + fileToProcess);
outputFile = theLFP.GetOutputFileName();
if (outputFile != null)
{
label.setText("input file: " +
fileToProcess + ", output file: " + outputFile);
ProcessInputDrWatsonFile PIDWF = new
ProcessInputDrWatsonFile();
if (PIDWF != null)
{
try
{
PIDWF.StartProcessing(fileToProcess, outputFile);
}
catch (IOException ex)
{
label.setText("EXCEPTION " + ex.getMessage() + " Processing input
file: " + fileToProcess + ", output file: " + outputFile);
}
}
}
}
else
{
break;
}
if (!display.readAndDispatch ()) display.sleep ();
}
display.dispose ();

}
}

Jeff Kish wrote:
> Hi.
> I have an swt app and I'm working in eclipse.
>
> I'm trying to figure out the best way to fit a status dialog up that
> will allow me to report records processed etc and make cancel /pause
> processing buttons available.
>
> I'm pretty rust so a pointer to a code snippet or actual code would be
> appreciated.
> Thanks
> Jeff
>
> p.s. here is my main. basically the'processingToDo' method puts up a
> couple of file dialogs to get input and output file names, and then
> reads one file and writes the other.

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.)

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
(object orientation)? I ask because it's usual for the main method to
not be doing much at all apart from setting up a few things - e.g.
instantiating some objects, then calling methods on those objects to
kick everything off. I would work on solidifying your understanding of
OO and learning to program in a less procedural manner before moving
onto more advanced things like threading, GUIs, etc. Get comfortable
with walking before you start running and all that....

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. Another concern is the reporting back of
the progress to the user in a dialog. Keep these concerns separate by
having a class for each: so, you could have a FileCopier[1] class, and a
ProgressDialog class.

[1] Obviously, if you really do want to be doing just file copying, look
at the existing options in Java for doing that task. Don't reinvent the
wheel.

As for examples of progress dialogs, did you try google? I googled for
"java progress dialog" and the third link was:
http://javaalmanac.com/egs/javax.swing/ProgMon.html

Try googling!


[[Some more advanced design concepts for later on: be aware that you
reduce the coupling between the copier class and the progress dialog
class (e.g. by using a software design pattern known as "Listener" AKA
"Observer" to have the progress dialog listen to the file copier for
progress events - this stops the file copier having to actually know
anything about a progress dialog). Make reporting of progress generic
(e.g. by programming to an ProgressListener interface that you create,
or similar).]]

On Mon, 10 Apr 2006 11:27:46 GMT, Alex Hunsley <>
wrote:

>Jeff Kish wrote:
<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
>(object orientation)? I ask because it's usual for the main method to
>not be doing much at all apart from setting up a few things - e.g.
>instantiating some objects, then calling methods on those objects to
>kick everything off. I would work on solidifying your understanding of
>OO and learning to program in a less procedural manner before moving
>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
>having a class for each: so, you could have a FileCopier[1] class, and a
>ProgressDialog class.
>
>[1] Obviously, if you really do want to be doing just file copying, look
>at the existing options in Java for doing that task. Don't reinvent the
>wheel.
>
>As for examples of progress dialogs, did you try google? I googled for
>"java progress dialog" and the third link was:
>http://javaalmanac.com/egs/javax.swing/ProgMon.html
>
>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
>class (e.g. by using a software design pattern known as "Listener" AKA
>"Observer" to have the progress dialog listen to the file copier for
>progress events - this stops the file copier having to actually know
>anything about a progress dialog). Make reporting of progress generic
>(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

Jeff Kish wrote:

> 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/tutor.../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/tutor...c/threads.html

Progress bars are very simple in concept, but quite difficult to realize.

--
Nigel Wade, System Administrator, Space Plasma Physics Group,
University of Leicester, Leicester, LE1 7RH, UK
E-mail :
Phone : +44 (0)116 2523548, Fax : +44 (0)116 2523555

On Tue, 11 Apr 2006 09:48:01 +0100, Nigel Wade <> wrote:

>Jeff Kish wrote:
>
>> 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/tutor.../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/tutor...c/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

Jeff Kish wrote:

> On Tue, 11 Apr 2006 09:48:01 +0100, Nigel Wade <> wrote:
>
>>Jeff Kish wrote:
>>
>>> 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/tutor.../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/tutor...c/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.

--
Nigel Wade, System Administrator, Space Plasma Physics Group,
University of Leicester, Leicester, LE1 7RH, UK
E-mail :
Phone : +44 (0)116 2523548, Fax : +44 (0)116 2523555