FullCalendar

The simplest usage of a BitFullCalendar is passing a list of events. Everything else comes with defaults: the month view opens first, the toolbar navigates and switches views, and clicking a day - or an event - opens the built-in add and details dialogs. Tab reaches the grid once and the arrow keys walk it from there; Enter or Space on a day (or a time slot in the day and week views) starts a new event, Alt and Shift with an arrow key move and resize a focused event, and Escape closes any dialog.

Settings carries the calendar's preferences: the time format, the hour the grid scrolls to, the month badge style, the agenda grouping, and everything the sections below configure. The user can change most of them from the settings gear, and those choices are written back onto the same instance - so a re-render of your page never reverts what they picked.

Narrow the day and week grids to the hours you actually schedule with Settings.VisibleStartHour and Settings.VisibleEndHour, and choose how finely each hour is divided - and how far drags and resizes snap - with Settings.SlotDurationMinutes (any divisor of 60). The same window and slot size drive the Timeline day and week layouts. Press and drag down a column to select a range - the new event opens already spanning it - or turn that off with Settings.AllowRangeSelection. Switch to the Day or Week view to see it.

Settings.HiddenDays removes weekdays from every date grid - the week, month and year views and the Timeline week layout - which is all it takes to render a work week. Settings.FirstDayOfWeek overrides the day the week starts on when the culture's own answer is not the one you want, and Settings.ShowWeekNumbers adds the ISO-8601 week number to the month grid and the week view's time gutter.

Set IsAllDay on an event to take it off the hour axis: it moves into the all-day row above the day and week grids, its badge shows the "All day" label instead of a clock time, and the details dialog reports the dates it covers rather than a time range. Events spanning more than one date already land in that row; the flag is what lets a single-date event join them. The built-in add/edit dialog offers the same switch.

Choose how overlapping event cards are arranged in the day and week views with Settings.EventLayout. Overlap (default) cascades the cards on top of each other, while Stack places them side by side in equal-width columns. Switch to the Day or Week view to see the difference - pick a layout below, or toggle it from the settings gear ("Stack overlapping events").

Replace the content of an event card per layout with DayEventTemplate, WeekEventTemplate, MonthEventTemplate, and TimelineEventTemplate. The calendar keeps owning the card's placement, colour and drag/resize behaviour - the template only fills it.

Supply Resources to enable Timeline mode, where rows are resources (rooms, machines, people) and columns are time. Events are matched to a row through their Resource id, anything unmatched falls into a trailing "Unassigned" row, and dragging a block between rows reassigns it. The add/edit dialog gains a resource picker as soon as the calendar has resources to choose from.

MinDate and MaxDate fence in the dates the calendar can reach. The prev/next buttons disable at the edges, out-of-range days are dimmed and inert, a bound Date outside the window is pulled back in, and a drag or a save that would land outside it is refused with a notice instead of moving the event out of sight.

Turn Settings.AllowEventOverlap off to prevent double booking: a drag, a resize, or a dialog save that would put two events on the same resource at the same time is refused, the calendar shows a notice, and OnRefused reports why. Individual events can also be frozen with IsReadOnly - they stay readable but cannot be dragged, resized, edited or deleted, whatever the rest of the calendar allows.

OnChange is raised whenever a user adds, edits, or deletes an event, with the new snapshot, the previous one (for edits and deletes), the Kind of change, and the Source it came from - a dialog, a drag, or a resize. Apply it to your own store in the handler so the change survives the next render.

The View, Mode, and Date parameters are two-way bound, so you can drive the calendar from outside and react to user-driven changes through OnViewChange, OnModeChange, and OnDateChange - the last of which also fires once on the first render, carrying the range you need to fetch events for, and only again when that range really moves, so picking another day of the week already on screen never asks you to re-fetch what you already have. The DefaultView, DefaultMode, and DefaultDate parameters set the initial values that are used when their two-way counterparts are not bound.

Capture the component with @ref to drive it from code without binding a parameter: GoToDate, GoToToday, NavigateNext, NavigatePrevious, ChangeView, and ChangeMode do exactly what the toolbar does - navigation is clamped into the allowed date window and a view is clamped into the allowed set - while GetVisibleRange reports the inclusive start and end dates currently on screen.

Previous

Today

Next

Day view

Month view

Read visible range

Render the calendar with a localized culture (here Persian, fa-IR) and override the UI strings through a customized BitFullCalendarTexts instance. The culture decides the calendar system, the month and day names, the first day of the week, and the writing direction - a right-to-left culture flips the whole layout on its own. This example translates most of the available strings: toolbar, view/mode tabs, filters, settings panel, search/agenda, dialogs, form fields, validation messages, and resource labels.