This question is locked. New answers and comments are not allowed.
Depending on the number of items at the end of the list, you can often see the previous sticky header For instance in your sample application, the phone book allows you to select Sticky Header and depending on the number of items at the end of the list, you occasionally see the previous header.
For example, if you add "Xander Guthrie2" and "Xander Guthrie3" to the Contacts.txt file and then scroll the phonebook sample to the bottom of the list slowly past W to X, you will see a point at which the W should be an X as it is covering the X below entirely.
For example, if you add "Xander Guthrie2" and "Xander Guthrie3" to the Contacts.txt file and then scroll the phonebook sample to the bottom of the list slowly past W to X, you will see a point at which the W should be an X as it is covering the X below entirely.
1 Answer, 1 is accepted
0
Hi Wayde,
Thanks for writing.
What you are describing is indeed reproducible and we are aware of it. However, we are facing a couple of limitations that come from the native ScrollViewer element that we are using to implement the scrolling functionality in RadJumpList. As you may already know, as of Windows Phone 7.5 Mango Microsoft introduced an optimized scrolling mechanism that utilizes another thread to perform the scrolling. This makes things easier for UI Virtualization which happens on the UI thread thus making the scrolling smooth as there is no need to wait for what's happening on the UI thread. Since all the scrolling happens on a dedicated thread, the values of the ScrollViewer are updated there and not directly accessible from the UI thread. They are synched in certain intervals and that's the reason why we are not able to update the value of the sticky header based on a pixelwise calculation of the scrolling position. In fact, the scrolling parameters are synched on the UI thread in case you scroll with 1/4 of the size of the scrollviewer or when you release your finger from the screen.
I hope this makes things clearer for you.
Let me know in case you have further questions or need assistance.
All the best,
Deyan
the Telerik team
Thanks for writing.
What you are describing is indeed reproducible and we are aware of it. However, we are facing a couple of limitations that come from the native ScrollViewer element that we are using to implement the scrolling functionality in RadJumpList. As you may already know, as of Windows Phone 7.5 Mango Microsoft introduced an optimized scrolling mechanism that utilizes another thread to perform the scrolling. This makes things easier for UI Virtualization which happens on the UI thread thus making the scrolling smooth as there is no need to wait for what's happening on the UI thread. Since all the scrolling happens on a dedicated thread, the values of the ScrollViewer are updated there and not directly accessible from the UI thread. They are synched in certain intervals and that's the reason why we are not able to update the value of the sticky header based on a pixelwise calculation of the scrolling position. In fact, the scrolling parameters are synched on the UI thread in case you scroll with 1/4 of the size of the scrollviewer or when you release your finger from the screen.
I hope this makes things clearer for you.
Let me know in case you have further questions or need assistance.
All the best,
Deyan
the Telerik team
Time to cast your vote for Telerik! Tell DevPro Connections and Windows IT Pro why Telerik is your choice. Telerik is nominated in a total of 25 categories.