Set background color of WPF Textbox in C code
Interview Questions practice on Codemia
Over 8,000 real interview questions from top companies, searchable by company and role.
Introduction
In WPF, a TextBox background is controlled by its Background property, which expects a Brush. If you want to change the color from C# code, the normal approach is to assign either a predefined brush from Brushes or a SolidColorBrush you create yourself.
The Simplest Programmatic Change
If you already have a TextBox instance, the direct code is straightforward:
That works because Brushes.LightYellow returns a reusable SolidColorBrush.
If you need a custom color rather than a predefined one, create a brush explicitly:
Both examples are valid. The only difference is whether the color comes from WPF's predefined brush set or from your own RGB values.
A Complete Window Example
Here is a minimal code-behind example that changes the background when a button is clicked.
This is the most common pattern in smaller WPF applications.
Using A Dynamic Color Choice
Sometimes the color depends on validation state or application logic. In that case, compute the brush in code.
This is useful when the UI should react to user input, parsing results, or remote status values.
If you need more exact colors, use ColorConverter or FromArgb.
Remember That WPF Uses Brush, Not Color
A common beginner mistake is trying to assign a Color directly:
That fails because Background expects a Brush, not a Color. Wrap the color in SolidColorBrush or use a member from Brushes.
That small type distinction explains many compile errors around WPF styling code.
UI Thread Requirements
WPF controls must be updated on the UI thread. If the background change happens after background work, marshal back to the dispatcher.
If you update MyTextBox.Background from a worker thread directly, WPF can throw a cross-thread access exception.
Code-Behind Versus Styles
Changing the background in C# is fine for event-driven logic, but not always the best long-term styling approach. If the color is purely a visual rule based on control state, a XAML style or trigger is often cleaner.
Still, code-behind is appropriate when:
- the color depends on runtime data not easily expressed in XAML
- a one-off event changes the control state
- you are building or modifying controls dynamically
So the right answer is not that code is wrong. It is that code should be used for behavioral logic, while general styling rules are often better expressed declaratively.
Common Pitfalls
- Assigning
Colors.Reddirectly instead of aBrush. - Updating the control from a background thread.
- Creating many custom brushes when a predefined brush from
Brusheswould do. - Using code-behind for styling rules that belong in a reusable XAML style.
- Forgetting that disabled controls may render with theme-specific visuals that affect the perceived color.
Summary
- Set a WPF
TextBoxbackground by assigning aBrushtoBackground. - Use
Brushes.SomeColorfor simple cases. - Use
new SolidColorBrush(...)for custom colors. - Update WPF controls on the UI thread.
- Prefer XAML styles for reusable visual rules, but use C# when the color depends on runtime behavior.
Related reading
- Set database timeout in Entity Framework
- Set focus on textbox in WPF
- Set global hotkeys using C
- Set System.Drawing.Color values
- Set timeout for webClient.DownloadFile
- Set Visual Studio Code to be global Git editor on OSX
- Setting an object to null vs Dispose
- Setting Objects to Null/Nothing after use in .NET

OOD Fundamentals
Master object-oriented design from first principles, SOLID, design patterns, and classic interview problems with hands-on coding.
View the courseTrack what you have practised
A free account saves your progress, solutions and study plan across every problem on Codemia.
Interview Questions practice on Codemia
Over 8,000 real interview questions from top companies, searchable by company and role.