Currently the scheduler widget determines the layout based on device type. Unfortunately this does not provide a fully responsive design. Modern day responsive websites should look good on any sized screen regardless of device type. There is also the issue that with new devices constantly coming out the list of devices being checked may become out of date quite quickly. Another consideration I have when I design an app is that one may not be viewing something full screen on a laptop or desktop computer. If this is the case then a page can look horrible due to the fact that an assumption is made on screen size because it is a windows device. I've also seen laptops with screens as small if not smaller than some tablets which also effects the screen size assumption.
Being web developer for a very long time I understand the complexities that would be involved in this change so I'd also like to provide an interim solution that may (but may not be) easier to attain. In working with your scheduler I had the idea of putting my own logic in to force moble/tablet view. I was able to accomplish this with very little code except that manually switching the mode (setting the mobile setting to phone or tablet) doesn't work for the scheduler. If that could be fixed it would at least provide a workaround for the above feature until you figured out how you wanted to handle it long term.
Thank you,
Brandon
If the CurrentTimeMarker is enabled (it is by default), the resources are grouped, and events with different resource values (about 70) are loaded for the current day, a significant performance deterioration is observed.
With the CurrentTimeMaker disabled or the events loaded for a date different than today (past or future) the performance issue is not exhibited.
MVCSchedulerCurrentTimeMarker.zip
No exceptions are thrown, but the Scheduler becomes unresponsive.
There should be no performance hit, regardless of CurrentTimeMarker being enabled/disabled.
Regression introduced in R2 2018.
The mobile mode of the Scheduler must be turned off.
Reproducible in the demos.
The moveStart event does not fire and the event cannot be moved.
The moveStart event fires and the event can be moved.
The Editor has an Encode option that when enabled allows Html tags to be submitted encoded.
This feature request is for a similar option in the Scheduler. A possible scenario could be an Editor nested in the Scheduler's custom editor. Currently the value of that field will be submitted not encoded regardless of the nested Editor's Encode option value. Having the option of enabling encoding of the values of the Scheduler fields would allow Html tags to be sent encoded.