Sorted Collection woes with ProgressDialog...

I posted just before ( its not showing up thou ) about some odd
behaviour I'm getting with SortedCollections, I've just tracked it down
to the fact I changed some code to wrap the building of said
SortedCollection with a ProgressDialog operation: - when doing this I
don't see any of the items in the collection.  I guess I need to
"commit" the collection or something?

Mark Derricutt wrote:

> I posted just before ( its not showing up thou ) about some odd
> behaviour I'm getting with SortedCollections, I've just tracked it
> down to the fact I changed some code to wrap the building of said
> SortedCollection with a ProgressDialog operation: - when doing this I
> don't see any of the items in the collection.  I guess I need to
> "commit" the collection or something?

Mmm, seeing as the original post isn't coming through, I'll repeat.

I have some code thats returning a SortedCollection, but recently, its
started returning 0 entries, if I inspect the returned object I see
theres objects in there, but there not accessible.  I can see the items
in the right hand table/list where I can sort them, but they're not
listed in the left portion under 'a SortedCollection' at all.

If I remove the ProgressDialog wrapping on the code it works fine....

Mark Derricutt wrote:

> I have some code thats returning a SortedCollection, but recently, its
> started returning 0 entries, if I inspect the returned object I see
> theres objects in there, but there not accessible.  I can see the
> items in the right hand table/list where I can sort them, but they're
> not listed in the left portion under 'a SortedCollection' at all.

This shows the problem:

foo := SortedCollection new.
(ProgressDialog operation: [:progress| foo add: 'boo'.]) show.

"foo size" should be 1, but is 0, but if you inspect foo, you'll see
'boo' in it.

Mark Derricutt wrote:

> This shows the problem:
>
> foo := SortedCollection new.
> (ProgressDialog operation: [:progress| foo add: 'boo'.]) show.
>
> "foo size" should be 1, but is 0, but if you inspect foo, you'll see
> 'boo' in it.
>
Switching to showModal solved the issue... mmm.

"Mark Derricutt" <[hidden email]> wrote in message
news:co5t1s$[hidden email]...
Mark

I can only reproduce your strange result if I add "foo size." as a third
line and then send "Display it" to the whole caboodle. If I execute the two
lines above and then separately display foo size it comes out correctly as
1. The reason is clear if you look at the class comment for ProgressDialog,
which  says:
"The various [instance creation] methods accept a <monadicValuable>
operation which is evaluated in a background process."
Presumably, if you run the three lines in one go, you are calling foo size
before the background process has completed. On the other hand, showModal
doesn't return until the progress display closes, by which time foo has been
updated and reports its new size.

HTH

Peter

Mark Derricutt wrote:

> If I remove the ProgressDialog wrapping on the code it works fine....

Don't forget that ProgressDialog launches a background Process to do the work.

    -- chris

Mark,

>>If I remove the ProgressDialog wrapping on the code it works fine....
>
> Don't forget that ProgressDialog launches a background Process to do the work.

One way to fix it would be, at the bottom of the block, to post a
deferred action to update the GUI.  The idea is to do all of the work,
waiting on servers, etc. on a background thread (so the user still has
some control over the program) and then use a deferred action to make
the GUI update, which is quick.

An alternate suggestion would be to start a background process to add to
the list (also by posting them as deferred actions) as new items become
available.  If you want to be really slick about it, you can add
provisional items that serve as placeholders until the data becomes
available.  I once looked at a newsreader that did that with downloading
group names from a server, and it was much nicer than "please wait while
we use your dialup connection to download 2^35 headers so you can
subcribe to one group whose name you already know".

Per David's question the other day, it is attention to these kinds of
design considerations that will make your "slow" Smalltalk code blow the
doors off of the compiler-switch-optimized competition.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]