Hi Ralph,

On Sat, Sep 11, 2010 at 1:05 AM, Ralph Boland <rpboland@gmail.com> wrote:
> Hi, i don't know why things are done the way they are...
> Is your question how the exception mechanism works, or why it is
> needed to be done with an exception? as opposed to say doing it
> some other way?

> The direct answer to your question is that given it is implemented in
> terms of exceptions, the signal is needed to trigger the
> defaultAction, or to allow someone higher up in the stack to trap it
> and redirect the notification.

> cheers,
> Mike


I am no expert on Exceptions but I do understand this.
What I don't understand is WHY ProgressInitiationException
is used and why a signal is sent to its instance to get the ball rolling.

Could not SystemProgressMorph be modified to handle this?

Alternatively, could not some other new (non-exception) class handle
the logic where an instance of that class is created and gets the ball
rolling without sending a signal to itself? �For me, currently, this
is the more intuitive way to do things. �Why use signals when they
are not needed? �(Or are they needed for some reason unknown to me?)

The modifications I am planning to make to the ProgressDisplay
package look easier if I get rid of the signal handling.
But I don't know what I will be breaking or what functionality will
be lost if I get rid of the signal handling.
So I need to know WHY?

I tried to answer your question the first time round but as I looked at the code I found that I didn't understand it, and so gave up on my explanation :). �It seemed to me that the reason for using a signal was to handle nesting. �One raises the�progress initiation signal�in the wrapper to the action block to get progress to display in the right progress bar. �If the signal is uncaught then its defaultAction would open up a new progress bar with one progress strip and initiate processing of the progress block, providing a handler for the progress initiation signal. �If the signal is caught (by the handler provided at the first level) then the existing progress bar is extended with a new progress strip for the nested progress. �At least that's how I thought it worked but I couldn't work out how the handler worked.

If I were writing it I would still use the signal to find if the progress was nested but I /would not/ put the code in the defaultAction. �Instead the signal would answer if it was nested and all the code would be at the point where the signal is raised. For this one can use a simple Notification, using its tag to disambiguate it e.g.

[Notification new tag: #progressBar; signal]
on: Notification
do: [:ex|
ex tag == #progressBar ifTrue: [ex resume: true].
ex pass] true

So e.g.

outerBarOrNil := Notification new tag: #progressBar; signal.
... if nested add to the existing bar otherwise create a new bar ...
[actionBlock value: bar]
on:�Notification
do: [:ex|
ex tag == #progressBar ifTrue: [ex resume: bar].
ex pass]

my 2�

If you can make the tests pass with simpler code then go for it!

best
Eliot



Regards,

Ralph Boland

> On Fri, Sep 10, 2010 at 4:37 AM, Ralph Boland <rpboland@gmail.com> wrote:
> > I posted the following earlier to the Squeak list but didn't get a responce.
> > Hopefully someone on the Pharo list can help me. ?I need this information
> > so I can make some planned changes to the ProgressDisplay package I released
> > a while back.
> >
> > -----------------------------------------------------------------------------------------------------------------
> >
> > A SystemProgressMorph is used to display progress while some computation
> > is being done. ?Furthermore the progress bars can be stacked to show progress
> > of component computations within a computation.
> > This I understand and understand most of the code.
> > But not All.
> > What I have trouble with is understanding why a ProgressInitiationException
> > is needed. ?In particular, String>>displayProgressAt:from:to:during:
> > does:
> >
> > ProgressInitiationException
> >
� �display: self
> > � � at: aPoint
> > � � from: minVal
> > � � to: maxVal
> > � � during: workBlock.
> >
> >
> > This method sets a few variables and then does:
> >
> > � � � �^self signal
> >
> > This signal is caught where upon a SystemProgressMorph is started or
> > extended with
> > an additional progress bar.
> >
> > But I don't understand why sending a signal to a ProgressInitiationException
> > is needed to get the ball rolling,
> >
> > Can someone please explain why things are done the way they are?
> >
> >
> > Regards,
> >
> > Ralph Boland

_______________________________________________
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project