Inspector properties

The inspector is generated from C# descriptors in InspectorCatalog.cs, with categories, editor types, bounds, choices and component-specific availability. Updates preserve editor focus; category expansion is remembered. Search filters properties, and Custom Properties… appears immediately below the search.

Edit several controls and recognize overrides

Ctrl/Shift+click or marquee-select controls to edit their compatible common properties together. Differing values are shown as mixed; an edit applies the chosen value to eligible controls as one design operation. Control identity and component-specific properties still belong to individual controls.

Changed inspector values are marked and offer a reset action. Color fields include swatches for presets and recent choices. A reset restores the inspector default; it does not override active declarations in component CSS.

When component CSS overrides a property, the inspector identifies the override and offers Use panel value to remove the relevant declaration. A separate notice identifies layout-shifting CSS such as padding or borders on a form. Review the removal before saving custom source; intentional CSS still takes precedence over inspector appearance. See component customization.

Border sides chooses which edges draw a border: all, none, top, bottom, left, right, top,bottom, left,right, top,left,right, or bottom,left,right. For example, bottom makes a panel act as a divider. Border width, style and color still determine the visible line. Layout calculations account for the chosen edges in Design and Preview.

Properties are contextual. Root position is omitted, input settings appear on applicable inputs, and layout providers control the fields they own. Name is separate from render identity; names must be unique identifiers. IDs are stable keys used by renderers, persistence and scripts.

Locked controls remain selectable but cannot be moved, resized, deleted or edited. Unlocking remains available. Locking the form does not lock children recursively. Enabled/Visible control runtime interaction; Design preserves selection.

Layout and styling

MaximumWidth/Height of zero uses the available parent/canvas limit. Size constraints apply to property edits and resize handles. Margin consumes parent space. Free-position containers support Dock/Anchor; managed layouts own child placement. See Dock and Anchor.

Custom CSS and Z-index live in Custom Properties → Styles, rather than separate inspector fields. Scoped :host styles override ordinary appearance settings. Keep position and sizing in Layout to preserve designer geometry. Nonvisual popup components style their runtime popup, not their designer tray. The editor also contains script.js and custom JSON values.

Design appearance and applied sources are saved in .forma projects and participate in Undo/Redo. Appearance metadata currently belongs to Builder; moving the styling contract into the shared Core API is still separate work.

Properties from JavaScript

Use forma.get, forma.set and forma.bind with exact camelCase keys and types in runtime properties. Code suggestions reflect supported component keys. Inspector labels do not automatically become script properties, and read-only status fields cannot be set.

const enabled = forma.bind("timer", "enabled");
forma.on("click", () => {
  forma.set("timer", "interval", 1000);
  enabled.value = !enabled.value;
});

Attach that example to a Button, with a Timer named timer. Numeric setters take numbers rather than quoted strings. Runtime writes affect the Preview copy; they do not edit the saved design. Bridge updates are asynchronous.

Remaining proposal items

• Visual Events-tab authoring and generated C# handlers; JavaScript event handlers already work in script.js.
• AutoSize, explicit AutoScroll controls and further layout/alignment settings.
• Additional TextBox options such as CharacterCasing and WordWrap.
• Custom attributes, RenderMode and application AllowDrop configuration.
• A visual binding editor beyond the current reactive scripting API.
• Form BackgroundImage and further native window configuration properties.
• A shared Core styling/property contract.

The original property proposal includes future ideas. Use the current component reference for available fields and exact ranges, and the roadmap for priorities.