Lock selection and visibility control

[Adam Salvo]

I have a stakeholder who likes the way the data is visualized in the TImeBar control, but thinks that in it's current form, it offers to much functionality and would be confusing to the end user (for the record, I disagree). What they would like to see the selection range and visible range locked (disable the click+drag the ends of the selection window and visible bar). The user could still scroll the selction box, and visible bar, but would not be able to change the range. We have a list of presets which gives the user the ability to change the range to day, week, month, quarter and year, and clicking on one of those changes the range of the selection and visible bar.

I didn't see anything that offered this functionality out of the box. I was looking at the available properties and events and thought that I could use the SelectionChange event in conjunction with binding the SelectionStart and SelectionEnd properties and a bunch of code to try to reset the SelectionStart/End if the end user tried to change the range, but get the updated Selection value thru the SelectionChange event if the user moved the selection window. I didn't actually try this out, it was just an idea.

I noticed that there was not a VisibleChange event, just VisibleStart/End properties, so even if my idea for the selection value worked, I couldn't use the same approach for the visible slider. Even if I wasn't trying to satisfy this stakeholder's request, I'd still like to see a VisibleChange event that works the same way as the SelectionChange event.

[Yavor]

Hi Adam Salvo,

Thank you for using RadTimeBar! Your feedback is most welcome!

Here when we designed the API we tried to be as minimalistic as possible, because we wanted first to hear from our customers how they are going to use it. From your scenario I understand that you need the following features that are currently missing from RadTimeBar:

• Disable ViewPort and SelectionThumb resize;
• Disable selecting groups / items with the mouse;
• VisiblePeriodChanged event *;
• Set the current drill level (Month, Week, Day, etc.) *;

Currently the timebar uses smooth scrolling. This means that each time you change the visible range by moving or resizing the scrollbar, the VisiblePeriodStart / End are changed. If you bind to them (or listen to the event) will result too many invocations. Another option is the ability to sustain the smooth scrolling functionality that currently exists, but notify only when the operation of changing the visible range has completed (leaving the mouse or the keyboard).

The last one is a little bit tricky, because the timebar can display hundreds of years at a time in the viewport and automatically calculate what is the best drill level that it should display for item and group. If you set it manually there are 2 options - display the new levels anyway, even if they cannot fit on the screen, and zoom-in/out automatically to show the new drill level. The first one can be a little bit dangerous and can lead to a severe performance hit, because setting the current drill level to Day when you are viewing a period of 100 years can result in too many boxes.

Again I want to thank you for your feedback. Please tell us what you think of these features and how you want them implemented. Of course, everyone is welcome joining this discussion!

Greetings,
Yavor Ivanov
the Telerik team