Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsWhite Papers
Discussion GroupsFirst AidDatabasesJavaBeansGUIJava 3DVirtual MachineCORBASecurityToolsGeneral
Java DirectoryOpen Source ProjectsSample Book ChaptersUser GroupsWeb Resources
Related Topics
Databases.NETMore Topics ...

Java Forum / General / April 2006

Tip: Looking for answers? Try searching our database.

how best to put a notify/cancel status dlg up during file processing of swt app

Thread view: 
Jeff Kish - 10 Apr 2006 11:58 GMT
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 ();
   
    }
}
Alex Hunsley - 10 Apr 2006 12:27 GMT
> 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.

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).]]
Jeff Kish - 10 Apr 2006 14:49 GMT
<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



Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.