The effect depends on the concrete control type. For example a label or button can become bigger or smaller to accommodate a longer or shorter caption.

Default is false, ie no auto-sizing

BaseBounds and BaseParentClientSize determine the distance to keep from Parent's sides, when a side is anchored to the Parent (akLeft...), and the Parent is resized.

In "normal" reading mode (left-to-right, LTR) text entry starts at the left, text is almost left justified, and vertical scrollbars sit at the right side of the control.

In right-to-left mode text entry starts at the right, text is almost right justified, and vertical scrollbars sit at the left side of the control.

In a bidirectional environment these different placements and adjustments can be configured (swapped) in various (but not all) ways.

(Allows RTL languages such as Arabic and Hebrew to be used)

Wild guess: The default mode is established by the platform, RTL reading is not supported on all (Windows) platforms.

The outer border determines the minimal distance to sibling controls, the inner border is the area between the control's BoundsRect and ClientRect.

When a control sits in a cell of a table (Grid) control, its horizontal and vertical alignment inside the cell can be specified, too.

The BoundsRect rectangle describes the TopLeft and BottomRight coordinates of the control, relative to its parent.

The values are based on the Top, Left, Width and Height properties of the control.

Set BoundsRect to move and/or resize the control. This can reduce flicker, occuring otherwise when Top, Width etc. are set individually.

The rectangle describes the placement of the control when its Parent is changed later.

Setting the rectangle also sets a flag, indicating that the values are available.

By default, the Caption is the same as the control's Name in the Object Inspector, and the developer must set it explicitly to some different text.

Only TWinControls have a client area, for other controls ClientOrigin is the same as Origin.

Note that this value is the position as stored in the object, not always in sync with the widget.

The default Color is the same as the parent window Color. If the color is clDefault then the result will need to be passed through GetDefaultColor to resolve clDefault. Convenience routines which obtains the color resolving clDefault and ParentColor are also provided as TControl.GetColorResolvingParent and TControl.GetRGBColorResolvingParent

Default is dmManual, meaning that dragging must be started in code.

Set to dmAutomatic to allow the user to drag this control. In this mode dragging can start immediately (on left mouse button press) or delayed, after the mouse has been moved away by a number of pixels (Threshold).

In normal operation all mouse messages are sent to the control under the mouse pointer. Mouse messages also can be sent to a capturing control, e.g. when a control is dragged.

Applications should capture mouse events only for special purposes, and release the capture as soon as a the target position has been determined. Limited user feedback is possible while the mouse is captured, not all application controls will work properly so long.

A mouse click is associated with the default action for controls, and is often the ONLY event handled in user code.

The reaction on an click can be specified by a user supplied method, and/or by selecting an action from a supplied ActionList

Double-clicking is much more common in a Windows environment than in Unix or Linux, where single-clicking is the default method for selecting an object. However, in all environments there could be valid use for a double-click, and a method should be supplied if appropriate.

Unlike for a drag-dock operation, no default action is associated with an drag-drop; the OnDragDrop handler is the only way to do something meaningful on an drag-drop.

By default all mouse wheel actions are translated into scroll events. Write an OnMouseWheel handler to react on turns of the mouse wheel.

The OnMouseWheelUp and OnMouseWheelDown handlers are notified only, they are not suited for customization of mouse wheel events.

This event is triggered after the Width, Height, ClientWidth or ClientHeight of the control has changed. During autosize the size can change multiple times, but only the last change triggers the OnResize.

Use OnResize to react on size changes. To also react on moves, use the OnChangeBounds event.

If you want to customize the resize behaviour, use OnConstrainedResize instead.

Common mistake: Keep in mind that ClientWidth and ClientHeight can change even when Width, Height stays the same. For example when the theme changes, the Width and Height remain the same, but the changed frame reduces the ClientWidth and ClientHeight. This does not happen that often under Windows, but it happens quite often on other platforms.

Especially it is not sufficient to write only a TForm.OnResize handler to resize all controls on the form. This is a common bug in Delphi applications.

The handler can provide a special DragDock object, otherwise a default object is created.

The handler can provide a special DragControl object, otherwise a default object is created.

When the Parent moves or hides, all its children move or hide together with it.

Every TControl must have a Parent, else it is never shown.

The Parent of a floating form is Nil.

Set the parent last to reduce updates. For example: Button1:=TButton.Create(Self); Button1.Name:='Button1'; Button1.Caption:='Click me'; // parent is not set, so it does not update the whole form Button1.Parent:=Form1; // set parent as last, the LCL now applies all properties

Delphi/VCL: Parent must be set first under Delphi, because many properties work differently if they are set before or after Handle creation. The LCL applies the properties when the Handle is created.

When True, the Hint text is shown when the mouse hovers over the control.

Display of the actual hint is controlled by OnShowHint.

This is the character string, shown in controls with visible text content (TEdit...).

The Delphi VCL implementation stores Text mostly in the widgets, using the virtual Get/SetTextBuf methods to exchange text between widgets and VCL. This means a lot of text copies and message handling in WM_GETTEXT and WM_SETTEXT.

The LCL instead (typically) stores Text in a field of the control, and transfers it from/to the widgets only when required.

To maintain VCL compatibility, the virtual RealGet/SetText methods have been introduced, which read or write the Caption string directly.

The default Get/SetTextBuf implementation calls the RealGet/SetText methods, resulting in a string-to-PCHAR and another PCHAR-to-string conversion. But as long as Get/SetTextBuf is not overridden, Get/SetText can (and does) safely call RealGet/SetText immediately, to avoid beforementioned conversions.

To keep things optimal, LCL components should always override RealGet/SetText; Get/SetTextBuf is only kept for compatibility.

Visible is set to True by Show, or to False by Hide. Calling these methods is equivalent to setting the Visible property.

WindowProc is set to by default.

When you ever change WindowProc, then remember the previous setting and delegate all unhandled messages to that method.