I love the Checkboxmode of the DataBoundListBox but unfortunately have a few issues, mainly regarding layout effects.
- The vertical positioning of the checkbox is sub-par. It's top border should be inline with the top position of the first control in the listitem, but it's always higher. I have seen in your demo app that you are fixing this by setting a minus margin on the listitem's LayoutRoot. That can bring the item on the same vertical position as the checbox but unfortunately eats up vertical margin to the pivot control header above. It's too near after this and also the "scrolling free room" that should be right above the first item is gone. There should be a way to align the Checkbox manually as this would be easier than aligning the whole other content to fit the checkbox.
- Also it causes horizontal positioning problems. When layouting your controls strictly by the guidelines by Microsoft and having, for example 12px left margin on your controls in your listitem, the item is positioned 24px too far right when enabling (not yet activating) CheckboxMode. So you have to remove the 12px margin, which would be ok ... but you have to also set a -12 margin somewhere else to clear the other 12px it's positioned too far right. Here it get's complicated ... you can't set it on the individual controls or on the LayoutRoot control of your listitem as in this case, when activating CheckboxMode the checkbox would come horizontally too close to the item content. So you have to set it on the whole DataBoundListBox control ... which would also be ok somehow if you don't use things like an EmptyDataTemplate that would be aligned 12px too far left in this case. So you would have to set an additional +12 margin on that again. So it becomes a real mess as you have to custom realign nearly everything to get a WP7-conform layout. Edit: Just for info, you are doing this -12 "fix" in your own demo project too.
- When using multiline textblocks I get scroll position issues - the activated CheckBox mode takes additional horizontal space and so depending on the content, 2-line-textblocks might become 3-line-textblocks. Of course, this isn't avoidable when using multiline textblocks. But because of the changed vertical space usage of one or more items, the scroll position isn't valid anymore and the user is thrown anywhere in the list and the item he clicked to activate the CheckBoxMode is out of sight. The DataBoundListBox should handle this case, remember the vertical scroll position of the clicked item within the current visible area and adapt the global list scroll position so that the item is, for the user, in the same place as before. And of course the other way around if the user deactivates checkbox mode again.
- Not that much of a problem, but i also noticed that the Checkbox mode click inidcator is also always as high as the whole item, including possible margins used for listitem spacing. I have no idea how you could fix that, and I think it's not as problematic as the other issues, but maybe you'll find a way to better influence this behaviour, maybe by addind another container template around the item so margins for spacing can be applied to that or whatever ... just an idea ;)
Thanks for any solutions or feedback ... you see, it's a bit problematic for me to use this currently, and the most important issue is #3 for me ... as #1 and #2 can be fixed good enough (except vertical space to pivot header) by wild realigning of all used controls ;)
8 Answers, 1 is accepted
Thanks for writing and for your extensive feedback.
The CheckBox Mode in RadDataBoundListBox is a unique feature and therefore we are always open to hear from our customers and improve its behavior so that it better suits their needs.
1. There is a property which allows you to define a custom style for the checkbox and thus provide custom margins for it so that it is correctly aligned with the contents on your item:
We are also going to update our example since the approach of using a custom style for the checkbox is better than adjusting the content of the items itself.
2. During the process of implementation of this feautre in RadDataBoundListBox we were inspired by the native checkboxes behavior in the mail client in the Windows Phone 7 OS. There, the listbox is in a pivot item and the checkboxes indicator that popups when activating this mode by tapping on the left edge of an item is positioned exactly at the edge of the screen. The pivot item has left margin of 12 px; the checkboxes indicator has width of 24 px and in the case of RadDataBoundListBox it is positioned in the bounds of the control which implies that the control itself should be positioned exactly at the edge of the screen so that the indicator appears on the right place. To position RadDataBoundListBox starting exactly at the edge of the screen when it is put in a pivot item, we need to apply -12px left margin. In this way, when the IsCheckModeEnabled property is set to true and the 24px space is accomodated for the indicator (by shrinking the containers), the content of the containers, in case no internal margins are applied, should be vertically aligned with the title of the parent pivot item. So it would be easier for you to apply -12px left margin to the whole RadDataBoundListBox control instead of the containers and also adjust your EmptyContentTemplate by applying 24px left margin so that it appears aligned to the title of the parent pivot item.
In general, the checkboxes support implies some custom adjustments so that it behaves in a way similar to the native mail client. If you come up with some better approach of improving this behavior, we are open to discuss it.
3. Indeed, loosing the focused items in the viewport just by activating the checkboxes mode is not a good user experience and we will consider a possible way to overcome this behavior. We will try to do this for our Q2 2011 SP1/Q3 2011 Mango SP1 release which is scheduled for the next week.
4. The height of the indicator is mapped to the height of the corresponding visual container. We will consider introducing a property which will allow for defining a vertical margin that will allow you to adjust its appearance.
I hope this is helpful.
Do not hesitate to get back to us in case you have further feedback or need assistance.
the Telerik team
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
thank your for your fast reply and your extensive feedback.
- Thank you, didn't noticed this CheckBoxStyle and this is the perfect solution. It would be good if you update your example as as soon as I saw that you were doing it also like that I thought there won't be another possibility and didn't investigated further.
- Thank you for the explanation, makes sense now to me. Maybe you should update your documentation with this info as when you just enable Checkbox mode, it seems like buggy behaviour on first sight as nowhere is mentioned that we should apply -12px margin to the listbox control to achieve a correct layout and why.
- Too bad it isn't fixable that easy, I'd really hoped I can have a fix soon after your first post ;), but its perfectly understandable. I can't really avoid text wrapping in my app for at least some lists where I want to use this feature, so hopefully you will be able to find a good solution for that. Until then I will have to live with that and maybe I find some tricks to optimize the behaviour ... or will offer my users an alternate way until then how they can achieve the tasks when they aren't satisfied by the checkbox behaviour.
- That would be great ... what I need is a way to have this indicator as high as the actual content is ... so it should be auto-calculated but ignore possible margins on top or bottom of the listitem that are used for spacing. But as I said, that's really a minor problem.
Thanks for writing back and for your understanding.
We already do have some ideas how the issue with the checkboxes mode and the text wrapping could be fixed but they all include some tradeoffs and we are still in the process of evaluating them.
As for the documentation regarding the layout question - we will make sure to update it accordingly with a topic explaining how to use the RadDataBoundListBox control wich its checkboxes mode in a pivot control in a way compatible with the Microsoft's guidelines.
Do not hesitate to get back to us in case you have further questions or need assistance.
the Telerik team
I found a few other issues/suggestions for Chechboxmode:
- It would be great if the CheckedItems collection would be bindable or if there would be a bindable version of it. Currently using checkbox mode is a bit complicated in MVVM scenarios. I know that I can let the CheckboxMode set a property on my business object depending if it's checked or not, but I don't like that approach too much and in some circumstances, it's also not really possible to use it, for example if you are using the same instance of an object in different lists. It would be best to have a bindable collection. But not a big issue, I use the the binable property in my app and it works for me.
- When activating Checkboxmode, the item on which the Checkboxmode was activated is not automatically selected. If you look at Microsoft's implementation, for example in the mail client, the item where you activated checkbox mode gets also preselected. I think that makes sense and should be also in your control. I didn't found a way to find out on which element the checkboxmode was activated so I also have no way to manually check the item currently.
- This leads directly to my next suggestion: it would sometimes be good to know on which item the user clicked to activate checkbox mode. An additional property in the EventArgs telling me the DataItem would be awesome.
- When the last item is unchecked, the Checkbox mode should be deactivated automatically, like in the mail client for example. I can do this for myself of course but it would be great if it's done by default, maybe opt-out or opt-in with a property.
- Same thing for clearing the checked items: when closing/deactivating checkboxmode, all items should be automatically unchecked. I can also do this manually but as this is also the default behaviour in Microsoft's implementation, I think the control should do it by default, maybe again with an opt-out.
Except 2, this are only things I noticed during development and I thought I might suggest them to change. Nothing important.
Issue 2 on the other hand is something I can't influence currently myself so this is something I would need fixed with a future release, that would be great :)
Thanks for your valuable feedback. I have updated your account with 1000 Telerik points for taking your time to share your thoughts and ideas with us.
As for your points:
1. Currently, I can only say that we might analyze the possible ways to implement a bindlable checked items collection and see whether we will be able to do it for the near future.
2. This is a valid point and we will consider introducing an option which will make RadDataBoundListBox automatically check the tapped item when the checkbox mode is activated. Another possibility would be to extdend the EventArgs in the CheckModeActivated event to contain the item that has been tapped which will allow you to check it by adding it in the CheckedItems collection.
3. By introducing the extended EventArgs object in the CheckModeActivated event we will handle the scenario in your third point as well.
4. We have considered this option but we decided that we want to give more flexibility to the developers in terms of what will happen when enabling/disabling the check-mode of RadDataBoundListBox. So, currently you can do this manually. If we have more demand from our customers for an automated behavior, we will introduce an option for that.
5. This is not automatically done for the same reasons discussed above.
Thanks again for your time and do not hesitate to write back in case you have further feedback or need assistance.
All the best,
the Telerik team
Thank you for contacting us and for your feedback.
We will re-evaluate all the points here and see whether we will implement them in a future release. I agree with you that the behavior provided by the default mail application should be our base to step onto.
As for the exceptions you are experiencing we will do our best to isolate and fix them, provided a demo app that reproduces them.
Thanks again for your time. Let us know if you have other questions/suggestions.
the Telerik team