Scheduler

Realistic month with overlapping events, a multi-day span, and a weekday-recurring standup. Today's cell has 5 events — more than the 3-lane budget — so it overflows into a "+N more" popover. Drag an event to move it (ghost preview until you release); drag across empty days to create one.

Same event set, time-grid layout. Overlapping events are packed side by side, off-hours are shaded, and the red line tracks the current time. Drag moves an event across days/times as a ghost outline; drag the bottom edge to resize.

Flat chronological list across the next 30 days — the same events as the calendar views above, including recurring occurrences and multi-day spans, grouped by day.

CanDrop is a three-way gate evaluated before any drop commits: SchedulerDropResult.Reject, .Accept, or .AcceptWith(adjustment) to snap the drop to a different time than the user dragged to. Nothing mutates until CanDrop returns — dragging only ever moves a ghost outline. Try dragging the event onto the 15th (rejected) or the 22nd (accepted, but snapped forward one day) of this month.

Switch views with the toolbar and page with prev/next.

A 15-minute grid. The gutter still prints one label per hour and hour boundaries keep the stronger rule, so the day still reads as hours rather than 96 stripes. Drags snap to the grid unless SnapDuration says otherwise. Values that do not divide an hour are rounded up to one that does — rows have to tile an hour exactly or the labels drift away from the lines they name.

A rolling window of VisibleDays days. Unlike the week view it does not snap to a week start, and prev/next page by the window's own width, so consecutive pages tile the calendar instead of overlapping. The toolbar button appears only once you have chosen a width — an N-day view with no N is not a view.

Both calendars below hold the same events, read in two zones. Only events carrying a real instant move: a DateTime with Kind of Utc or Local denotes a point in time and can be re-read elsewhere, while an Unspecified value is a wall-clock reading that is already in whatever zone you meant — so setting a zone cannot silently shift existing data. Edits are converted back before they reach OnEventChange: what you get out is in the frame you put in. All-day events are dates, not instants, and never move.

SchedulerView.Timeline puts one row per resource and runs the time axis horizontally across days, weeks or months — the shape Outlook's scheduling assistant has. A different question from the resource view below: this one shows how a resource is booked over a stretch, that one shows who is where on a single day.

Overlapping bookings stack into their own lanes rather than drawing over each other, so a double booking is visible instead of hidden, and the row grows to fit. A booking running in from before the window is clamped to the edge, not dropped — a resource that is busy must never read as free.

SchedulerView.Resource lays out one column per entry in Resources — genuinely separate lanes, not just color-coding.

BuiltInEventDialog is off by default, because most apps already have their own appointment form wired through OnDateSelect and OnEventClick. Turning it on never displaces that: both callbacks still fire exactly as before, so the dialog is additive. Double-click a day to create, click an event to edit; saving reports through EventsChanged — the same channel a drag uses.

A SchedulerCalendar is which FEED an event came from, where a SchedulerResource is what it consumes — so calendars decide whether an event is shown at all. Click a chip to hide one; the button beside them splits the visible calendars into their own panes and merges them back. An event with no CalendarId belongs to no calendar and is never hidden.

A selection drawn in a pane reports that pane on SchedulerDateRange.CalendarId, so your own appointment form can file the new event into the column the user drew it in. It is null while the calendars are overlaid, where no single one owns the gesture.