Concepts

Building a Form vs Automating One

GPAL.Form builds a GUI that belongs to your workflow -- a window you design, with controls you place. GPAL.Application automates someone else's GUI -- a window that already exists, with controls you locate. They share a vocabulary (buttons, inputs, checkboxes) but solve opposite problems.

Show, ShowDialog, and Hide

Show displays a form without pausing the workflow, ShowDialog pauses execution until the form closes, and Hide closes it. Choosing between them determines whether the form is a blocking prompt or a live status window.

One Control, One Pattern

Every GPAL form control -- button, checkbox, input, combo box, grid, chart, and the rest -- is built the same way: a fluent chain of With... Settings, completed with a cast to the control's type -- for example, Input -- and handed to WithFormControl. Learn the pattern once and every control type follows it.

Data-Driven Forms: FillInFrom and CallAfterFillIn

A GPAL form isn't limited to one screen of static controls. FillInFrom can drive the same form through every row of a grid, file, or database query, with CallAfterFillIn running your logic between rows.

Tabs and Split Panes in GPAL Forms

GPALTab creates a new tabbed container directly in the WithFormControl chain. Each tab control passed creates a new tab and controls added after it go into that tab until the next tab control is added. Similarly, GPAL.HSplit and GPAL.VSplit add a split container; controls after the call go into the first pane, GPAL.SplitRight or GPAL.SplitBottom switch to the second pane, and GPAL.EndSplit returns to the parent container. Both compose freely: a split inside a tab or a tab inside a split is just a matter of order in the chain.

💬 Ask GPAL