Introduction to Windows Forms
Windows Forms (WinForms) is a GUI framework in .NET for building desktop applications with draggable, event-driven controls. Every window is an instance of a class inheriting from System.Windows.Forms.Form, and the Visual Studio designer generates a partial class file (Form1.Designer.vb) that instantiates and positions controls like Button, TextBox, and Label, keeping that generated code separate from the hand-written logic in Form1.vb.
Cricket analogy: A Form inheriting from System.Windows.Forms.Form is like every domestic team inheriting the same basic rules of cricket from the ICC — the shared foundation lets each team (form) still have its own unique lineup of players (controls).
Controls and the Designer
Public Class MainForm
Private Sub btnGreet_Click(sender As Object, e As EventArgs) Handles btnGreet.Click
If String.IsNullOrWhiteSpace(txtName.Text) Then
MessageBox.Show("Please enter a name.")
Else
lblOutput.Text = $"Hello, {txtName.Text}!"
End If
End Sub
End ClassThe Toolbox in Visual Studio lets you drag controls like TextBox, Button, Label, ComboBox, and ListBox onto the form's design surface, and the Properties window lets you set each control's Name, Text, Size, and Location without writing code. Control names should be renamed from defaults like Button1 to descriptive names like btnSubmit, since that name is what you'll reference throughout your code-behind, and every visible property change made in the designer is written as generated code into the InitializeComponent method.
Cricket analogy: Dragging controls from the Toolbox onto a form is like a captain arranging fielders on the pitch diagram before the match — placing each position visually rather than describing coordinates in words.
Event-Driven Programming in WinForms
WinForms applications are event-driven: instead of running top to bottom, the form sits idle in a message loop until the user interacts with it, and each interaction raises an event like Click, TextChanged, or SelectedIndexChanged. In VB.NET, the Handles clause on a Sub — as in Private Sub btnGreet_Click(...) Handles btnGreet.Click — statically wires that method to a specific control's event at compile time, which is why the designer automatically generates a stub handler when you double-click a control.
Cricket analogy: A form waiting in a message loop for events is like fielders standing ready in position, doing nothing until the bowler releases the ball and a specific reaction — catch, throw, run-out attempt — is triggered.
Beyond the designer-generated Handles clause, you can wire event handlers dynamically at runtime with AddHandler btnDynamic.Click, AddressOf Me.HandleClick, and remove them later with RemoveHandler. This is useful when controls are created programmatically, such as inside a loop that generates buttons at runtime, where there's no design-time control to attach a Handles clause to.
Layout and Anchoring
The Anchor property ties one or more edges of a control to the corresponding edges of its container, so the control resizes or repositions when the form is resized — for example, Anchor set to Top, Bottom, Left, Right makes a control stretch to fill available space in both directions. The Dock property instead snaps a control's entire edge to fill one side of its parent container (Top, Bottom, Left, Right, or Fill), which is commonly used for toolbars docked to the top and status bars docked to the bottom of a form.
Cricket analogy: Anchoring a control to all four edges is like a boundary rope that expands proportionally with the size of the ground being used for a match, always keeping the field's dimensions consistent.
Windows Forms controls are not thread-safe: updating a control's property (like lblStatus.Text) from a background thread throws an InvalidOperationException at runtime (or silently corrupts the UI in older .NET versions). Use Control.Invoke or Control.BeginInvoke to marshal the update back onto the UI thread, or use a BackgroundWorker/Task with proper synchronization instead of touching controls directly from worker threads.
Forms Lifecycle
A form fires a predictable sequence of lifecycle events: Load fires once when the form is about to be displayed for the first time, letting you initialize data before the user sees anything; Shown fires immediately after the form is first displayed, appropriate for actions that need the form to already be visible, like showing a centered dialog; and FormClosing fires before the form actually closes, giving you a chance to cancel the close (by setting e.Cancel = True) — for example, to prompt the user to save unsaved changes.
Cricket analogy: The Load event firing before the form is shown is like a pitch report delivered before play begins, letting captains prepare strategy before a single ball is bowled.
- Every WinForms window is a class inheriting from System.Windows.Forms.Form, with designer-generated code kept in a separate partial class file.
- Drag controls from the Toolbox and configure them via the Properties window; rename them from defaults to descriptive names.
- WinForms is event-driven — code runs in response to events like Click, wired via the Handles clause or dynamically via AddHandler.
- Anchor resizes/repositions a control relative to its container's edges; Dock snaps a control to fill one side of its parent.
- Never update a control's properties directly from a background thread — use Invoke/BeginInvoke to marshal back to the UI thread.
- The form lifecycle runs Load, then Shown, then eventually FormClosing (cancellable) and FormClosed.
- FormClosing's e.Cancel property lets you intercept and stop a close, e.g. to prompt for unsaved changes.
Practice what you learned
1. What does the Handles clause do in a VB.NET WinForms event handler?
2. Why should you avoid updating a Label's Text property directly from a background thread?
3. What is the difference between Anchor and Dock?
4. When does the FormClosing event allow you to cancel the close operation?
5. How can you wire an event handler to a control created dynamically at runtime, with no designer entry?
Was this page helpful?
You May Also Like
Events and Delegates in VB.NET
Understand how delegates provide type-safe function references in VB.NET, and how the Event/RaiseEvent/WithEvents system builds the observer pattern on top of them.
Async/Await in VB.NET
Learn how the Async and Await keywords let VB.NET applications perform non-blocking I/O and long-running work without freezing the UI or wasting threads.
ADO.NET and Database Access
Learn how VB.NET applications connect to relational databases using ADO.NET's connection, command, and reader objects, plus disconnected DataSets and transactions.
Related Reading
Related Study Notes in Programming
Browse all study notesApache Spark Study Notes
Programming · 30 topics
ProgrammingApache Flink Study Notes
Programming · 30 topics
ProgrammingHadoop Study Notes
Programming · 30 topics
ProgrammingSnowflake Study Notes
Programming · 30 topics
ProgrammingApache Airflow Study Notes
Programming · 30 topics
Programmingdbt (Data Build Tool) Study Notes
Programming · 30 topics