ListModel - updating the view after Element changes

Hi,

there's a funny thing going on.

1. When I select an element in Multicolumn (ListPresenter enhanced view)
list and make modifications to it in a popup dialog, the view gets
updated, all by itself, at least without me writing any trigger code.

2. But when I do the same in a ListPresenter default view, the view on
the object doesn't get updated.

How does this work?

Guenther

Günther,

> there's a funny thing going on.
>
> 1. When I select an element in Multicolumn (ListPresenter enhanced view)
> list and make modifications to it in a popup dialog, the view gets
> updated, all by itself, at least without me writing any trigger code.
>
> 2. But when I do the same in a ListPresenter default view, the view on
> the object doesn't get updated.

Could it be that the mulit-column list is wider and therefore more
likely to be uncovered by your dialog box?  We could debate whether it
makes sense for a partial uncovering to cause entire items to update,
but it would not surprise me if works that way.

This reminds me of a time that I had to open a Word **95** document, and
the only machine that could do it was a P5-60 or so with 8MB of RAM.
You would not believe how many times the file open dialog redrew itself
at each selection change :(

How should it work?  See #refresh: or #updateItem: in ListModel.  One or
the other is deprecated; IIRC, OA deprecated one of them in a patch and
then later decided to wait for a release to do it.  Details aside, the
idea is to tell the list model that the item has changed, and it will
inform the view.  You should not ordinarily need to do any triggering of
your own to make it work.

Have a good one,

Bill

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

Hi Bill,

nice you helping me out here again, I had a feeling you'd be there, helping.

Bill Schwab schrieb:
Sorry Bill,

this might be a missunderstanding.

What I meant is not that the view doesn't display, it just keeps
displaying *old* data.

But that is only so for the ListPresenter - Default view, in the
ListPresenter 'enhanced view' aka. multicolumn view the 'current' data
is displayed.

You too!!

Guenther

"Günther Schmidt" <[hidden email]> wrote in message
news:41e18585$[hidden email]...
The multi-column view is using a ListView in "virtual" mode, which is set up
to perform callbacks to get the display string, icon, etc. Every time the
view is repainted, the control will call back into Dolphin, and the text and
image blocks will be evaluated to get the display information.

The default view is using the simpler ListBox control, which does not
support the callback capability. This means it displays a fixed string for
each entry, until that entry is explicitly changed.

In both cases you should really trigger the update event. In the case of the
ListView this will do less work (essentially it just tells the control to
redraw the affected entry), but it is still necessary for reliable
operation. The updating is only working for you as a side effect of the
dialog appearing over the top of your view, requiring it to be repainted
when the dialog is closed. If the dialog appeared elsewhere (e.g. due to a
different display configuration), then it wouldn't update either.

Regards

Blair

Günther,

> this might be a missunderstanding.
>
> What I meant is not that the view doesn't display, it just keeps
> displaying *old* data.
>
> But that is only so for the ListPresenter - Default view, in the
> ListPresenter 'enhanced view' aka. multicolumn view the 'current' data
> is displayed.

I think we are indeed discussing the same phenomenon.  See the
#referesh:* methods in ListModel; I suspect they will do what you want.


Have a good one,

Bill

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

Hi,

After reading Bills and Blairs postings over and over again and with
digging through the documentation on the Wiki:

I've finally understood it.

Uff!


But one slight problem that remains ....

If the object exists multiple times within the same ListModel only the
first found instance gets updated.

Is there already a solution to use for multiple occurence of an object
within the same list or should I (try) to code my own?

Günther

Günther,

> But one slight problem that remains ....
>
> If the object exists multiple times within the same ListModel only the
> first found instance gets updated.
>
> Is there already a solution to use for multiple occurence of an object

I first hit this with trees, and typically end up creating wrapper
objects to avoid it.  You might do the same with your list.  In that
case, see #getTextBlock.  If there is one area of the VC (probably more
accurate to say the PAI) that I find a little lacking, it is editing
these blocks.  I manage it, but hesitate to explain how to do it for
fear that there is a much easier/better way that simply has not occured
to me.

Perhaps that VC IDE extension I keep threatening to write could do a
better job of it???

For your wrappers, you might want to try my CodeGenerator goodie, and
its "Generate Constructor" command in particular.

As an alternative to setting a #getTextBlock, you could change the
wrapper's print or display strings (#printOn:, #displayOn:), but I think
it is cleaner to use the blocks.  Put another way, when I use blocks, I
don't end up regretting it as I do when I customize print/display to
avoid using blocks ~:(

I recommend that you consider a changed presenter to be "dangerous".  By
that I mean that you should get everything ready to go, including any
workspace expression needed to run the newly changed code, then save
your image.  Then if you encounter problems during presenter/view
opening, you will have the option to debug for a while and exit w/o
saving changes.  Note that you can find yourself forgetting to save
changes at times, but you will not accumulate nearly so many zombie
views.  I use the same procedure with new external interfacing code,
where the penalty for mistakes can be a damaged image, and eventually
started treating presenters the same way.

Have a good one,

Bill


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

Günther Schmidt wrote:

> If the object exists multiple times within the same ListModel only the
> first found instance gets updated.

I think that's a bug.  When you tell a list model that an item has changed
(#itemUpdated:) it asks its SearchPolicy to find the index of the object, and
then does an #updateAtIndex: with that index. It never looks to see if there
are any other occurrences in the list.

I can't think of any reason why the "same" (according to the SearchPolicy) item
should not appear in more than one place in the list (unlike the case for
TeeModels, where it is forbidden).  So I think its wrong that the ListModel
should assume that there is only one such occurrence.

(Incidentally, for OA, ListModel>>updateItem:ifAbsent: should be in the
'updating' category instead of/as well as 'searching'.)

For some reason, the SequencableCollection hierarchy doesn't even have a
#indicesOf: method.  Here's my implementation (not that it isn't obvious,
but...).

    -- chris

!SequenceableCollection methodsFor!

indicesOf: target
 "Answer an <SequenceableCollection> of indices of the elements of the receiver
that are
 equal to the <Object> argument, target."

 | index stop stream |
#CUadded.

 index := 0.
 stop := self size.
 stream := Array writeStream.  "should this be of the same type as the receiver
?"
 [index := self nextIndexOf: target from: index+1 to: stop.
 index = 0 ifTrue: [^ stream contents].
 stream nextPut: index]
  repeat.! !
!SequenceableCollection categoriesFor: #indicesOf:!public!searching! !