When I looked through the code I imagined one could implement the
nesting by just maintaining a stack on the progress initiator sort of
like
...
On 11 Sep 2010, at 16:45, Eliot Miranda <[email protected]> wrote:
Hi Ralph,
On Sat, Sep 11, 2010 at 1:05 AM, Ralph Boland <[email protected]>
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 <[email protected]>
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
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
