I have a radScheduler at https://mine.hourmine.com/c/pCalendar.aspx?pa=casey (navigate to next week if everything is gray).
Right now I am showing "available" text via a background image in the open time slots. But this is less than ideal. What I want to do is to show the exact time of that slot - like 9:15am, 9:30am on the slot itself and make it look like a button so that it is easier for the end user to know which timeslot are they booking.
I tried to use the following code in RadScheduler1_TimeSlotCreated() event
Label lblStartTime = new Label();
lblStartTime.Text = e.TimeSlot.Start.ToShortTimeString();
lblStartTime.CssClass = "TimeSlotLabel";
But, I get a run-time exception that e.timeSlot.Control is null.
How can I do this?
13 Answers, 1 is accepted
This is a valid way of adding controls to the RadScheduler's Timeslot, however it will return an ArgumentOutOfRangeException if the index you are trying to add the control at with the AddAt() method does not exist. Try adding the label without specifying an index with the Add() method.
Thanks, that worked - you can see it at: https://mine.hourmine.com/c/pcalendar.aspx?pa=kernerchiro
However, I have two related issues:
- The available timeslot leaves a small area extending on top to the "unavailable" slot where the user can still click and book an appointment. How can I eliminate this?
- For some reason, when I load the page for the first time, the scheduler extends beyond the 6:40pm closing time. When I go the day view, it correctly shows the scheduler only until 6:40p. and when i come back to weekview from there, it again correctly shows the scheduler until 6:40pm (6:20pm being the last slot). The problem only happens when the page is first loaded. When I look in the debugger, the VisibleRangeEnd property shows 6:45pm for some reason.
1. This seems to be a custom CSS issue. You can try reducing the height of the rows a little bit:
2. The VisibleRangeEnd is a readonly property and should not have effect on the displayed hours. The hour range displayed in the views is controlled by the DayStartTime and DayEndTime properties. They can be set per view which allows to have different ranges in Day and Week views. Are you setting these properties in the markup or code behind? What value does the RadScheduler1.WeekView.DayEndTime property return on initial load and afterwards?
Appreciate the quick reply.
1. I think the issue might be some padding or margin on the timeslot that is not covered by the "unavailable" appointment laid on top of the timeslot. I am looking at the "inspect element" but cannot determine for sure what that is.
2. Yes, we are setting it in the code-behind. Even for the week view, you can see that when we navigate to the next week, the problem fixes itself. But I cannot figure out why the scheduler is showing that extra row after 6:10pm (with no time label). This is only a first load issue, once you navigate back and forth in the weeks it is no longer there, but when you refresh the page, you will see it again.
Is this the clickable area you have an issue with, because setting the row height makes it disappear at my side?
Which handler are you setting the DayEndTime property in? Does it behave the same way if you set it in the markup or in Page_Init/Page_Load handlers? What value does it return in Page_Load and does it change later in the page lifecycle?
I tried your suggestion for the clickable area. It removes the small slice, but has side effects. The whole scheduler's height gets affected and the time slots stop matching with the labels towards the end.
I will try to look at the other information you have asked for - maybe it has something that will help me resolve the issue.
I am setting it in the Page_Load():
radScheduler1.DayEndTime = new TimeSpan(0, BusinessHoursTo, 0);
It is not really an option to set it hardcoded in the markup, since different offices have different times.
Is that the right event to set it in?
The DayEndTime is set to 6:20pm in the PageLoad, yet when the first Appointment_Selecting() event happens, the VisibleRangEnd property for the scheduler is set to 6:30pm! Not sure what is causing this.
One final piece of data.
The VisibleRangeEnd is 6pm just before the call to set DayEndTime. As soon as I set the DayEndTime to 6:20pm, the VisibleRangeEnd jumps to 6:30pm. Looks like it only moves in 30 min. increments...
Please, try reproducing the issue in the attached sample website, use your custom CSS if necessary and post your modifications that lead to reproducing the observed behavior. This will give us a better idea of your scenario and configuration and will allow us to test the behavior at our end.
Telerik .dll files are omitted from the bin folder in order not to exceed the maximum allowed attachment size.
I can repro the issue fine on the main website, my clients repro it all the time and that's why they are mad at us because we are showing a time slot that should not be bookable (6:20p). Right now we are doing a manual workaround to adjust their close time to 6pm, but that makes them miss out a slot that can be booked (6:10p).
The issue is that there seems to be a limitation in the control that it can only have displayendtime in units of 15 minutes.
So as long as the DayEndtime is a multiple of 15 like 6:00p, the calendar looks ok. But when you set it to something like 6:20p, it automatically tries to adjust the VisibleEndTime to 6:30p. I have watched these values in the debugger and as soon as the DayEndTime is set to 6:20p, the VisibleEndTime automatically changes to 6:30p
I think I finally figured it out. For others who encounter such issues.
Turns out, it is important to set the MinutesPerRow at design time to a unit that is the lowest common multiple of all the possible minutes per row values you are going to set programmatically. For us it was 5 min.
Once it is set at design time, I think that gives the proper clue to the control to automatically set the VisibleEndTime according to a multiple of the MinutesPerRow.
Ivan - although I did not run your project, looking at your code gave me the idea to put the MinutesPerRow value at design time. So thanks for following up on this diligently.
I am glad the issue is resolved and thank you for sharing more details.