Hi all,
I am evaluating if the RadScheduler is fit for (our) use.
I have a very simple test project: a radscheduler with minimum plumbing (trivial datasource etc.)
If I set the DayEndTime to "23:40:00" and the MinutesPerRow to "26" I get the error:
"Microsoft JScript runtime error: 'this.cells.0.offsetHeight' is null or not an object"
in the line:
d.each(l.rows,function(){Array.add(n,this.cells[0].offsetHeight);
If I set the value of MinutesPerRow to "25" it does not crash, but 26 or higher and bam...
There are also other settings that crash but I report one here. It is reproducable on my system so it
never does not crash with the 23:40:00, 26 values.
Am I doing something wrong here?
regards,
Johan
8 Answers, 1 is accepted
Please accept my apologies for the late reply.
Actually I can not see any logic in setting the DayEndTime="11:40:00" and MinutesPerRow="26". By starting at 12:00:00 AM and adding 52 on each row you can easily find that you will exceed the 11:40:00 end and that's why you got error. I agree that we should catch such cases and do the neeedul to not get errors.
I've reported this as a bug in the RadScheduler and we will fix this soon. Here you can find the PITS Issue: Public URL.
P.S: I gave you points for reporting the bug. Please take a look the Points History in your profile.
Kind regards,
Veronica Milcheva
the Telerik team
Rank 1
Hi Veronica,
Unfortunately, I cannot follow your reasoning.
Please explain to me again where I do not get it.
I would expect MinutesPerRow to define the number of minutes that one row represents.
If it is set to 1, there would be 1440 rows in a full day.
If it is set to 1440, there would be one row in a full day.
If it is set to a value between 1 and 1440, there would be anything between 1 and 1440 rows in a full day.
I implemented a zoom function similar to the Wpf scheduler control on (http://demos.telerik.com/wpf/)
Controls > Data > Schedule View > Tick Frequency and Zoom
I limited the range of MinutesPerRow to [1,30]
So if MinutesPerRow = 1 the user has a very large scheduler, that is bad oversight over his appointment that day, but he can resize an appointment very accurately, that is, per minute.
And if MinutesPerRow = 30, the user has oversight over his appointment that day, but he cannot resize more accurate than per half hour.
Anything in between: well, you get it.
Now the settings of DayStartTime and DayEndTime would only function as a filter.
So if DayStartTime is set to, say, 8h and DayEndTime to 17h, there would be 9 hours = 540 minutes in the dayview, but this would not change the mechanics of the zoom.
If MinutesPerRow was set to 1, there would be 540 rows in the dayview
If MinutesPerRow was set to 30, there would be 18 rows in the dayview
If MinutesPerRow was set to a value between 1 and including 30, there would be somewhere between 1 and 18 rows in the dayview.
One more example:
If DayStartTime would be set to 01:00 and DayEndTime to 02:00
If MinutesPerRow was set to 1, there would be 60 rows in the dayview
If MinutesPerRow was set to 30, there would be 2 rows in the dayview
Anything in between: well, you get it.
Now I would not expect this setup to crash at any mentioned settings.
I would not have to handle any exceptions etc.
So please do not solve this bug the wrong way by sweeping some exception under the table (I do not say you do this but please if you should be seduced to do so, don't. Please).
I.m.o.there should be no exception but in stead the expected behaviour I described.
When I reported the bug, I chose to report one reproducible setting: DayEndTime=23.40 and MinutesPerRow=26
If this crashes, a good sw engineer i.m.h.o. would see there is something wrong, regardless of the logic or practicality of the settings.
This is smoke. So there is fire somewhere.
Please do not only combat symptoms. Solve the underlying problem.
regards,
Johan
Thank you for the detailed explanation of what you are trying to achieve and the logic of the MinutesPerRow propety for RadScheduler. Please let me explain what is the possible reason for the error:
Let's take the same settings that cause problems for you: MinutesPerRow = "26" , DayEndTime="23:40:00". You are correct that if we set the MinutesPerRow="1" we will have 1440 rows (24 hours per 60 minutes). Now with 26 minutes per row and end at 23:40 we'll have the following calculations: 1440 - 20 (comes from 23:40) = 1420 minutes. To determine the rows we need to divide 1420 with 26. The result is approximately ~54.6 rows. However note that RadScheduler displays rows grouped by 2:
The problem is that RadScheduler can not render 55 rows as they can not be represented in a group by 2.
Even after more investigation I found that it doesn't matter whether you've set the DayEndTime and DayStartTime properties. If you remove all other properties and leave only MinutesPerRow="26" - the javascript error with appear.
We'll inspect this further. Meantime you can set the MinutesPerRow property only for some values between 1 and 30 and not the whole range as on our "Customization" Demo.
Kind regards,
Veronica Milcheva
the Telerik team
Rank 1
I made an error:
If MinutesPerRow was set to a value between 1 and including 30, there would be somewhere between 1 and 18 rows in the dayview.
If MinutesPerRow was set to a value between 1 and including 30, there would be somewhere between 540 and 18 rows in the dayview.
Rank 1
I'm afraid I do not quite get your point. The RadScheduler should just be robust enough to handle the situation. Some design decision must be made what to do with partially filled groups.
regards,
Johan
I didn't understand why you think that when MinutesPerRow="30" there will be 18 rows in the DayView. The correct is 48 rows. Please take a look at our "Customization" Demo and check by yourself.
I already reported the bug and we'll inspect what causes the JavaScript error. The bug will be fixed for the next Release.
Thank you for your patience.
Regards,
Veronica Milcheva
the Telerik team
Rank 1
"So if DayStartTime is set to, say, 8h and DayEndTime to 17h, there would be 9 hours = 540 minutes in the dayview, but this would not change the mechanics of the zoom."
And 9 x 2 = 18.
Please don't let DayStartTime and DayEndTime out of the argument.
regards,
Johan
Yes, in this case when DayStartTime and DateEndTime properties are set - you are correct that there will be 18 rows in the dayview.
We'll do the needful to fix the bug and investigate the reasons for it.
Greetings,
Veronica MIlcheva
the Telerik team