This is a quick follow-up to my previous post.
Immediately after it I have made some research on the possibilities to solve the issue you are describing in your third point and it appears that with our current implementation this will not be as easy as it initially seemed.
In general, the implementation of our checkboxes mode aims to be more generic and to avoid any additional configuration steps for you to follow. Our aim is to allow using this feature by simply binding the listbox to a data source and playing with the corresponding properties: no specialized item templates etc.
Since when checkboxes are shown, item containers are shrunk to accomodate space for them. This shrinking is performed by reducing the width of the visual containers which implies layout passes. Doing this for all realized visual containers is slow and therefore we have optimized this by showing the checkboxes on the items in the viewport first, and after that, on dispatcher, toggling the rest of the items. As you may guess, to fix the error in the scroll offset implied by potential changes in the items' height after showing the checkboxes, we must wait for all containers to change their size and calculate the new scroll offset. With our current implementation this will not happen immediately and smoothly enough since non-viewport items, as mentioned above, are toggled asynchronously on the dispatcher.
For instance, in the Silverlight Toolkit for Windows Phone the checkboxes support is implemented in a specialized way to allow for having a static content at the right side of the container by shrinking only part of the whole container (a column of a grid which is the layout root). This, however, implies that you will have to define to data templates: one for the shrinkable content, and one for the static content.
Another possible way of implementing this behavior, which we also considered, is to translate the containers instead of shrinking them. This, however, will cause some of the content of your containers to be hidden. In case this content is important, this is not a desired effect.
As you may already have guessed, enabling the checkboxes feature implies some tradeoffs, especially when the aim is to make it more generic and bring it out of the context of the mail client on WP7. Therefore, we decided to postpone the fix for issue #3 in your original post and take our time to find the best approach to implement it (since the SP is already scheduled and the time is scarce).
For now, our advice would be to avoid using the text wrapping feature, i.e. item height based on item width in scenarios where checkmode is used.
I hope this is helpful and would like to thank you for your understanding.
Please let me know if you have further feedback on the other topics discussed above.
the Telerik team
Explore the entire Telerik portfolio by downloading the Ultimate Collection trial package. Get it now >>