Progress Monitor

Hi all

I have what seems a simple problem, but nothing I have tried seems to fix
it. I have a run which will take a minute or two to complete, and for
testing purposes I would like to show a separate window which gives a text
commentary on progress, adding one line of comment at each interesting
stage. I open a MultilineTextEdit in a separate shell, and I keep the edit's
text as an instance variable of the controlling class; whenever an
interesting event happens, a line is added to the instance variable and the
edit's #text: method is called to reset its contents. Problems:
a. The edit remains completely blank during the run, and all the comments
appear at the end of the run.
b. The edit window cannot always be kept visible, even when I send #beOnTop
to it.
c. The edit window cannot be closed by program at the end of the run; I send
#close and #exit to it, which blanks its contents but leaves it there.

I'm sure all these are simple to fix, and it just shows my inexperience. I'd
be grateful for any hints.

Thanks

Peter Kenny

"Peter Kenny" <[hidden email]> wrote in message
news:[hidden email]...
> I'm sure all these are simple to fix, and it just shows my inexperience.
I'd
> be grateful for any hints.

Maybe you could start playing with ProgressDialog, see how it works, and
take it as your starting point. Generally when you are in doubt, it is often
helpfull to see if something similar exists in image, and work from there.

rush
--
http://www.templatetamer.com/
http://www.folderscavenger.com/

Peter,

> b. The edit window cannot always be kept visible, even when I send
> #beOnTop to it.
> c. The edit window cannot be closed by program at the end of the run; I
> send #close and #exit to it, which blanks its contents but leaves it
> there.

These sound as if you are opening the window with code like:
    tp := MultilineTextEdit show.
And then trying to control it with code like:
    tp beTopMost.
or
    tp close.

If so then the problem is that #beTopMost and #close should be sent to a Shell
(or ShellView) not to a sub-component that is displayed inside the shell.  When
you do
    MultilineTextEdit show.
that creates a new MultilineTextEdit component, but since MultilineTextEdit
isn't a kind of Shell the system also (automatically) creates a new Shell to
contain it (actually it creates an instance of ShellView since ShellViews can
act as their own Presenters).  However the value returned by #show is the
component you originally asked for, not the containing shell.  To get the
shell, you can send #topShell to the component.

    tp := MultilineTextEdit show.
    sv := tp topShell view.

and then
    sv beTopMost.
or
    sv close.
should work OK.


> a. The edit remains completely blank during the run, and all the comments
> appear at the end of the run.

I'm not sure what's going wrong here.  I suspect its something to do with the
component only revalidating (and so repainting) itself in 'idle time' -- the
Transcript can suffer from the same problem.  One question: are you running the
code directly in the main user-interface Process, or are you #fork-ing a
background Process to do the computation ?

    -- chris

"Chris Uppal" <[hidden email]> wrote in message
news:424abbda$0$38043$[hidden email]... Chris

Actually I was partly doing what you suggest. I began with:
    report := MultilineTextEdit show.
and then used:
    report topShell beTopMost
when opening it and:
    report close.
    report topShell close.
when finishing up. The closing problem is now solved, simply by deleting the
'report close' and just sending the message to the Shell. However, I can't
get it to remain on top (but see below!).
>
>
> > a. The edit remains completely blank during the run, and all the
comments
> > appear at the end of the run.
>
> I'm not sure what's going wrong here.  I suspect its something to do with
the
> component only revalidating (and so repainting) itself in 'idle time' --
the
> Transcript can suffer from the same problem.  One question: are you
running the
> code directly in the main user-interface Process, or are you #fork-ing a
> background Process to do the computation ?

In fact I was running the code directly from the main UI process (I think -
it starts that way, but the code is actually using ActiveX to transfer data
to an Excel spreadsheet, so Lord knows which process that is running in) -
at any rate, the method that posts the progress messages is in the main UI
process. Just out of curiosity, I put the call to the main data export
procedure inside a fork block, and that changes things. The report shell now
appears on top, and the progress messages appear in clumps of 4 or 5 at a
time. So 2 1/2 problems out of 3 solved! Would it be any help to turn the
progress report into an observer that responds to events triggered by the
(forked?) data export process?

Thanks

Peter

Peter

> The report
> shell now appears on top, and the progress messages appear in clumps of 4
> or 5 at a time. So 2 1/2 problems out of 3 solved! Would it be any help
> to turn the progress report into an observer that responds to events
> triggered by the (forked?) data export process?

I can't see why using the Observer pattern should make the Windows APIs work
better ;-)

You could try doing
    report view update.
after each addition to the text.  That works perfectly for me, but I only
discovered View>>update yesterday, so I don't know how well to expect it to
work beyond my little test-case.

    -- chris

"Chris Uppal" <[hidden email]> wrote in message
news:424bac43$0$38044$[hidden email]...

> You could try doing
>     report view update.
> after each addition to the text.  That works perfectly for me, but I only
> discovered View>>update yesterday, so I don't know how well to expect it
to
> work beyond my little test-case.

Chris

Thanks - putting in update does the trick for me too!

Peter