Empty ListView

Hi,

Not sure if this is a bug, but I am sure it will cause them.

In D4, setting a ListModel with an empty list did not cause a
selectionChanged event to be triggered because of the guard clause in
TreeView>>refreshContents. In D5, the same guard clause does not guard
#onSelChanged.

To see the problem, create a shell with a listPresenter and evaluate:

    shell := MyShell show.
    shell listPresenter list: #(1 2 3)
    "make selection"
    shell listPresenter list: #()
    "D5 triggers #selectionChanged, D4 doesnt"

The comment in ListView suggests it is not a bug, but it would be a good
issue to highlight in the release notes.

Thanks,
Steve Waring

"Steve Waring" <[hidden email]> wrote in message
news:[hidden email]...
This is as a result of the fix for bug #718, i.e. that the ListView did not
trigger a selection change event on refreshContents, and in fact it applies
regardless of whether or not the new list is empty. Note that this was
inconsistent in D4 because if the ListPresenter.Default view was used (i.e.
a ListBox) then the selectionChanged event did get fired, but not for
ListPresenter.Enhanced list view. This can be demonstrated as follows,
comparing D4 vs D5.

l := ListPresenter show.
l when: #selectionChanged send: #bell to: Sound.
l list: #(1 2 3)
l selection: 1
l list: #(). "D4 does ring the bell"
el := ListPresenter show: 'Enhanced list view'.
el when: #selectionChanged send: #bell to: Sound.
el list: #(1 2 3)
el selection: 1
el list: #(). "D4 does not ring the bell"

In fact D5b3 eliminates a number of the selection change related event
inconsistencies and bugs that existed in D4 (and believe me, there we a lot,
mainly sublte ones caused by the inconsistencies in the underlying Windows
controls), and this is definitely something to look out for when upgrading
apps. Perhaps the most important of these is that the #selectionChanging:
event is now never fired as a result of a programmatic change. This event is
mainly intended to handle the case where one wants to prompt the user to
abort the selection change for some reason, and since in many cases the
programmatic changes could not be aborted (e.g. the selected item has been
deleted), this did not make sense. One manifestation of this was the loop of
prompts to save changes that used to occur when one deleted a class in one
class browser that had been modified in another. In D4 selection changing
events were generated for programmatic changes if the control itself sent
them (which the TreeView does). If one attempts to refuse a selection
changing event sent by the TreeView where that is not possible, then the
TreeView simply sends the event again the next time it is activated, and
will continue to do so until the cows come home.

Regards

Blair