Restore scroll position in LongListSelector after tombstone

Question

I am trying to work with a LongListSelector control from the WP7 Silverlight Toolkit. It took a bit of work, but finally I worked with my application. Unfortunately, I have some problems with the proper processing of the headstone process.

When the gravestone of the application (or the user goes to another page by selecting an item in the list), I save a copy of the topmost visible item in the list. I save it for both a class variable and a collection of application states.

ICollection<object> visibleItems = myLongList.GetItemsInView(); _lastItem = null; if (visibleItems.Count > 0) _lastItem = visibleItems.First(); IDictionary<string, object> state = Microsoft.Phone.Shell.PhoneApplicationService.Current.State; state["IndexByName_LastTopItem"] = _lastItem; 

Then, when the user returns to the page, I check one of the two values ​​(state or variable) and use it to restore the last scroll position.

 if (_lastItem == null) { if (state.ContainsKey("IndexByName_LastTopItem")) { _lastItem = state["IndexByName_LastTopItem"] as Chemical; } } if (_lastItem != null) Dispatcher.BeginInvoke(() => { myLongList.ScrollTo(_lastItem); }); 

This works great if the application does not contain a tombstone. In this case, I don't get any errors, but the list is completely empty until I touch it and drag it. As soon as I do this, it will appear at the top of the list. I took a look at the source for the control and found that when you call .ScrollTo (the object), it does not get a match. Further research showed that when searching for an item to scroll, it compares using == instead of Equals. I just overridden Equals and apparently by default == compares (by design) the links. When you restore a state item after a tombstone, the links do not match. I can override ==, but this is wrong. I can change and rebuild the control source to name equals instead (I tried and worked), but it was written by people much smarter than I, and I wonder if I just don’t understand this. Is there a better way?

Answer 1

This is the fix I encountered ...

Since the source code is freely available for the Toolkit, I finished editing the source code of LongListSelector to call .Equals instead of ==. It seems to work correctly for my use case, and I thought I would share it if someone finds it useful ...

in LongListSelector.cs find the GetFlattenedIndex function (object object) and replace

 if (item == _flattenedItems[index].Item) 

from

 if (item.Equals(_flattenedItems[index].Item)) 

and then in the same file find the GetResolvedIndex function (object, outside the context of the ContentPresenter contentPresenter) and replace

 if (node.Value.Content == item) // Nov 2010 Release // OR if (_flattenedItems[index].Item == item) // Feb 2011 Release 

from

 if (item.Equals(node.Value.Content)) // Nov 2010 Release // OR if (item.Equals(_flattenedItems[index].Item)) // Feb 2011 Release 

Indicate that the replacement depends on the tool download used!

Once you make these changes to the control, it will correctly match the objects specified in ScrollTo (object), even if the links are not equal, if you correctly override Equals for all types of objects displayed in your LongListSelector. Do not forget that this applies to your Grouping class, as well as to the product class, if you have a grouped list!

Answer 2

Can you try to get an item in a new list?

 var _goodReference = myList.FirstOrDefault(x => x.id == _lastItem.Id); if (_goodReference != null) Dispatcher.BeginInvoke(() => { myLongList.ScrollTo(_goodReference); });