ListView refresh

Hi all,

I've got a problem with refreshing a ListView in one of my views. I found
two methods trying to do this job, but they both have their downsides. First
let me explain a bit about the view. It is a monitor showing lines to be
executed. The lines form a sorted collection based on their scheduled
execution time. When executed they are removed from the list. However, some
of these lines can generate one or more new scheduled lines. Now that's
where the problem is. The list always starts with two items, the first being
an item scheduled for the start of the day and the other scheduled for the
end of the day. When the first one is executed, it generates somewhere
between 20 and 40 new scheduled lines.
 From model point of view everything works as it should, but the list view
gets 'its nickers in the twist'. The problem is that at first the listview
doesn't have a scrollbar as there are only 2 items in the list. Adding the
bunch of lines, a scrollbar should be added to the list. Now as I said, I
found two methods to update the list; #updateAll and #refreshContents.
#refreshContents redraws the whole list, which indeed does add the
scrollbar, but flickers every time it is called as it redraws the full list,
therefore I hoped to avoid this one.
#updateAll doesn't have the flicker problem, but does have the problem with
the scrollbar (both when it should be added and when it should be removed).
Now I could start messing about with manually checking whether the list
changes from needing the scrollbar and not needing the scrollbar and then
call the #refreshContents, but I was hoping that there is a more elegant
way.

Any ideas?

Thanks in advance,

Ted Bracht
www.tedbracht.co.uk

Ted,

Analogous to your #refreshContents, I have an app that uses:

 SessionManager current inputState queueDeferredAction:[
  aListPresenter list:aCollection.
 ].

It flickers too.

Rather than replacing the entire list, you might be able to identify changed
items and update them individually using #updateItem: etc. in ListModel, but
that's likely to turn one inefficiency (bad algorithm) into another (lots of
time in the Windows message queue) if many items change.  It fights
conventional wisdom, but it you want fast and efficient UI elements, write
them yourself in Smalltalk so you can tune the behavior and skip the need to
wash everything through the message queue.  I offer the MoenTree as an
example of what can be done.

Have a good one,

Bill

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

I refresh individual items in the SUnit Browser, which seems to work OK -
but I'm not dynamically adding and subtracting items in an event response.

jlo

"Bill Schwab" <[hidden email]> wrote in message
news:aqopb1$eri$[hidden email]... changed
> items and update them individually using #updateItem: etc. in ListModel,
but
> that's likely to turn one inefficiency (bad algorithm) into another (lots
of
> time in the Windows message queue) if many items change.  It fights
> conventional wisdom, but it you want fast and efficient UI elements, write
> them yourself in Smalltalk so you can tune the behavior and skip the need
to