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

Discussion in 'Java' started by Jeff Kish, Apr 10, 2006.

  1. Jeff Kish

    Jeff Kish Guest

    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, Apr 10, 2006
    #1
    1. Advertising

  2. Jeff Kish

    Alex Hunsley Guest

    Re: how best to put a notify/cancel status dlg up during file processingof swt app

    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).]]
     
    Alex Hunsley, Apr 10, 2006
    #2
    1. Advertising

  3. Jeff Kish

    Jeff Kish Guest

    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, Apr 10, 2006
    #3
  4. Jeff Kish

    Nigel Wade Guest

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

    --
    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
     
    Nigel Wade, Apr 11, 2006
    #4
  5. Jeff Kish

    Jeff Kish Guest

    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/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
     
    Jeff Kish, Apr 11, 2006
    #5
  6. Jeff Kish

    Nigel Wade Guest

    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/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?


    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
     
    Nigel Wade, Apr 12, 2006
    #6
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Henry Law
    Replies:
    2
    Views:
    2,983
  2. Replies:
    1
    Views:
    401
    Jason Whitlark
    Jul 25, 2003
  3. Ramon F Herrera

    Where can I download SWT? (SWT homepage)

    Ramon F Herrera, Dec 5, 2007, in forum: Java
    Replies:
    11
    Views:
    4,054
    Ramon F Herrera
    Dec 6, 2007
  4. Replies:
    9
    Views:
    1,785
    Piet van Oostrum
    Jul 26, 2009
  5. A@Rome
    Replies:
    1
    Views:
    120
    A@Rome
    Dec 9, 2004
Loading...

Share This Page