[vwnc] [Bug?]vw7.6 SelectionInList setList:selecting:; SequenceView not displaying "correctly" in some cases
Locked
[vwnc] [Bug?]vw7.6 SelectionInList setList:selecting:; SequenceView not displaying "correctly" in some cases
 
|
setList:selecting: says that:
"Finally, if newList has fewer items scroll the list widget back as needed so that at least one list item (e.g. the last) remains visible" It would be really nice if it at least scrolled back to the new selection instead... Or if the new list contains less items than can fit in the SequenceView's bounds, it actually displays all of them. This "worked" due to a bug in makeVisible: in 7.5, but since it's been corrected in 7.6, if I call setList:selecting: replacing a large, scrolled down list with a small list, only the last item will show, and the rest (including selection, unless that happened to be the last item on list) will be "hidden" above, since the scrollbar is grayed out. I believe the method that would need to be updated is: SequenceView updateSelectionChannel:. Cheers, Henry _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: [vwnc] [Bug?]vw7.6 SelectionInList setList:selecting:; SequenceView not displaying "correctly" in some cases
|
|
The more I think about it, the issue really seems to me to do with the
dependants updating, in a general case where both the one issuing a change, and one of the dependents, leads to updates in another dependent. (ie: listHolder and selectionIndexHolder in SelectionInList bot affect the SelectionView in this example) What happens is since the selectionIndexHolder is first in listHolder's dependents list, when listHolder triggers a valuechange on its list, the selectionIndex ends up updating the components selectionIndex before it has replaced it's list with the proper content. Which means, if you replace a list with a larger list, which has a selectionIndex > size of the old list, it's impossible for the SelectionView to scroll to the correct index, since it's not gotten notification about the new list yet. Is there any other solution to this problem other than making sure in such cases, the other dependents which leads to updates in common components will receive the notification last? Basing proper execution on the order of dependants seems like a bad thing to me, but in this case, I really can't see any other obvious solutions... Cheers, Henry Henrik Johansen wrote: > setList:selecting: says that: > "Finally, if newList has fewer items scroll the list widget back as > needed so that at least one list item (e.g. the last) remains visible" > It would be really nice if it at least scrolled back to the new > selection instead... > Or if the new list contains less items than can fit in the > SequenceView's bounds, it actually displays all of them. This "worked" > due to a bug in makeVisible: in 7.5, but since it's been corrected in > 7.6, if I call setList:selecting: replacing a large, scrolled down list > with a small list, only the last item will show, and the rest (including > selection, unless that happened to be the last item on list) will be > "hidden" above, since the scrollbar is grayed out. > I believe the method that would need to be updated is: > SequenceView updateSelectionChannel:. > > Cheers, > Henry > > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > > > _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: [vwnc] [Bug?]vw7.6 SelectionInList setList:selecting:; SequenceView not displaying "correctly" in some cases
|
|
My bad, guess that's what the updateModelSelecting: call I removed was
for... So, basically, the listHolder updates the listIndexHolder, which makes the selectionView refresh its model if needed before updating the index, and then not really do anything when the listHolder wants to update it. If I understand it correctly. Huh. My current take is: updateSelectionChannel: anIndexOrNil (anIndexOrNil isNil or: [anIndexOrNil = 0]) ifTrue: [self updateSelectionChannel] ifFalse: [| lastIndex range indx| indx := selectionChannel value. range := self visibleIntervalForBounds: self bounds. (lastIndex := self model value size) < range size ifTrue: [self makeVisible: 1] ifFalse: [|emptyIndx| self updateModelSelecting: anIndexOrNil. (emptyIndx := range last - lastIndex ) > 0 ifTrue: [indx := indx - emptyIndx]. self scrollBy: 0 @ (anIndexOrNil - indx) * self lineGrid. ]. self selectionIndex: indx] Two changes: - Instead of scrolling to show only the lowest object of the new list has fewer items than the first index in range, it shows all items by making the first item visible if the new list is smaller than the visible list. - If there would be empty slots at the end of the list after scrolling, it instead scrolls up to fill all the empty slots. Cheers, Henry Henrik Johansen wrote: > The more I think about it, the issue really seems to me to do with the > dependants updating, in a general case where both the one issuing a > change, and one of the dependents, leads to updates in another dependent. > (ie: listHolder and selectionIndexHolder in SelectionInList bot affect > the SelectionView in this example) > What happens is since the selectionIndexHolder is first in listHolder's > dependents list, when listHolder triggers a valuechange on its list, > the selectionIndex ends up updating the components selectionIndex before > it has replaced it's list with the proper content. > Which means, if you replace a list with a larger list, which has a > selectionIndex > size of the old list, it's impossible for the > SelectionView to scroll to the correct index, since it's not gotten > notification about the new list yet. > Is there any other solution to this problem other than making sure in > such cases, the other dependents which leads to updates in common > components will receive the notification last? Basing proper execution > on the order of dependants seems like a bad thing to me, but in this > case, I really can't see any other obvious solutions... > > Cheers, > Henry > > Henrik Johansen wrote: > >> setList:selecting: says that: >> "Finally, if newList has fewer items scroll the list widget back as >> needed so that at least one list item (e.g. the last) remains visible" >> It would be really nice if it at least scrolled back to the new >> selection instead... >> Or if the new list contains less items than can fit in the >> SequenceView's bounds, it actually displays all of them. This "worked" >> due to a bug in makeVisible: in 7.5, but since it's been corrected in >> 7.6, if I call setList:selecting: replacing a large, scrolled down list >> with a small list, only the last item will show, and the rest (including >> selection, unless that happened to be the last item on list) will be >> "hidden" above, since the scrollbar is grayed out. >> I believe the method that would need to be updated is: >> SequenceView updateSelectionChannel:. >> >> Cheers, >> Henry >> >> _______________________________________________ >> vwnc mailing list >> [hidden email] >> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc >> >> >> >> > > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > > > _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
«
Return to VisualWorks
|
1 view|%1 views
| Free forum by Nabble | Edit this page |