DEV Community: s-iguchi09

Why a WPF DataGrid Edit Does Not Reach the ViewModel When Save Is Clicked, and How to Use CommitEdit

s-iguchi09 — Fri, 16 Oct 2026 17:31:09 +0000

A user types into a DataGrid cell and clicks Save in the toolbar without leaving the cell. The grid still shows the new text, but the view model saves the old value. No exception, no warning.

This is a short summary. The full article, with a table of measured results for each save path on .NET 10, is here:
Why a WPF DataGrid Edit Does Not Reach the ViewModel When Save Is Clicked

Three things get in the way

Toolbar, menu, and Ctrl+S never end the edit. ToolBar and Menu are focus scopes, so focus snaps back to the cell before the command runs. A KeyBinding never moves focus at all. Only a plain button outside the toolbar happened to work.
CommitEdit() with no arguments is not enough. Called while a cell is being edited, it only commits the cell into the pending row. The source keeps the old value, and a later ICollectionView.Refresh throws InvalidOperationException.
Unconvertible input blocks the commit. With abc in an int column, the commit returns false. Saving anyway stores stale data.

The fix

Commit the whole row at the start of the save, and stop if it fails:

bool committed = grid.CommitEdit(DataGridEditingUnit.Row, true);
if (!committed)
{
    // Tell the user about the invalid input and do not save.
    return;
}

To keep the view model unaware of the DataGrid, the full article passes this call in from code-behind as a Func<bool>. It also explains why UpdateSourceTrigger=PropertyChanged and FocusManager.IsFocusScope="False" are not real substitutes.

A Japanese version is also available.

Binding to a WPF UserControl's Own Dependency Property from Inside the Control

s-iguchi09 — Thu, 15 Oct 2026 17:42:47 +0000

You add a Title dependency property to a UserControl, the caller passes Title="{Binding HeaderText}", and the debugger confirms the value arrived. Yet <TextBlock Text="{Binding Title}"/> inside the control shows nothing.

This is a short summary. The full write-up, with measurements on .NET 10 and every edge case, is here:
Binding to a WPF UserControl's Own Dependency Property from Inside the Control

Why it happens

A binding with only a path resolves against DataContext. Inside the control, DataContext is inherited from the consuming view, so {Binding Title} looks for Title on the caller's view model, not on the control. The Output window reports the view model as the DataItem, which gives it away.

Two cases hide the problem completely: when the view model happens to have its own Title (a wrong value shows, no error), and when DataContext is null (blank, no error).

The fix in one line

Give the inner binding an explicit source:

<TextBlock Text="{Binding Title,
           RelativeSource={RelativeSource AncestorType={x:Type local:InfoCard}}}" />

ElementName on a named root works too. If the control references many of its own properties, set DataContext on the inner root panel (not on the UserControl itself) and keep plain {Binding Title} below it.

What to avoid

DataContext = this in the constructor makes the inside work but breaks the caller's binding. It only shows up when the caller passes a binding instead of a literal, so it often survives until the control is reused.

The full article also covers ContextMenu vs. inline Popup, DataTemplate name scopes, and when you need BindsTwoWayByDefault.

A Japanese version is also available.

Fixing a RelayCommand Whose CanExecute Does Not Update the Button State in WPF

s-iguchi09 — Wed, 14 Oct 2026 17:45:30 +0000

You fill in the required field, CanExecute now returns true, and the Save button stays grey. A hand-written RelayCommand declares CanExecuteChanged but never raises it, so the button never asks again.

This is a short summary. The full article, with a table of what each call does to Button.IsEnabled on .NET 10, is here:
Fixing a RelayCommand Whose CanExecute Does Not Update the Button State in WPF

What the measurements show

A new CanExecute result alone changes nothing. The button re-queries only when CanExecuteChanged fires.
The way you raise it has to match the implementation. CommandManager.InvalidateRequerySuggested() and ordinary typing reach only a command that forwards to RequerySuggested. A command with its own event ignores both and needs its own raise method.

The fix

When a view model property decides executability, keep your own event and raise it from the setter:

public event EventHandler? CanExecuteChanged;

public void RaiseCanExecuteChanged()
    => CanExecuteChanged?.Invoke(this, EventArgs.Empty);

// In the view model
set { _name = value; SaveCommand.RaiseCanExecuteChanged(); }

When executability follows focus or selection instead, forward add/remove to CommandManager.RequerySuggested. The full article covers when each fits, the cost of requerying every connected button, and why both raises belong on the UI thread.

A Japanese version is also available.

Why WPF Input Limits Such as MaxLength Do Not Apply to Values Set from Code or Bindings

s-iguchi09 — Sun, 04 Oct 2026 17:15:39 +0000

A TextBox has MaxLength="50", yet an 80-character name loaded from an old record shows up in full and gets saved again. The same happens with a DatePicker range, a snapping Slider, and a disabled TabItem.

This is a short summary. The full article, with tables for seven limits across user input, code, and bindings on .NET 10, is here:
Why WPF Input Limits Such as MaxLength Do Not Apply to Values Set from Code or Bindings

What the measurements show

These limits restrict the user, not the property. Assignment from code passed six of the seven. MaxLength, CharacterCasing, and PasswordBox.MaxLength are documented this way.
DatePicker leaks even for users. A date outside the range typed into its text box became SelectedDate, and DisplayDateStart then moved back to that date.
Slider.Maximum coerces only the screen. Set to 150 through a TwoWay binding, the slider showed 100 while the view model kept 150.
A disabled tab is still selectable by setting SelectedIndex.

The fix

Guard the value in the view model, and keep the control limits only as typing aids. For a length, record an error through INotifyDataErrorInfo instead of truncating:

_nameErrors.Clear();
if (value.Length > MaxNameLength)
    _nameErrors.Add($"Name must be at most {MaxNameLength} characters.");
ErrorsChanged?.Invoke(this, new DataErrorsChangedEventArgs(nameof(Name)));

For a volume, clamp and round in the setter so the source and the slider agree. The full article also explains why a read-only period needs Mode=OneWay on DisplayDateStart.

A Japanese version is also available.

Binding to the Parent DataContext from Inside a WPF DataTemplate

s-iguchi09 — Sat, 26 Sep 2026 08:21:22 +0000

Each row of an ItemsControl has a Delete button bound to {Binding DeleteCommand}. The button looks enabled, but clicking it does nothing. The command lives on the parent view model, while everything inside the template gets the row item as its DataContext.

This is a short summary. The full article, with a table per binding style and measurements inside ContextMenu and ToolTip on .NET 10, is here:
Binding to the Parent DataContext from Inside a WPF DataTemplate

Why nothing looks wrong

When the binding fails, Command stays null. A null command leaves IsEnabled at True, so the screen gives no hint. The Output window does: its DataItem names the item type instead of the view model.

The fix

Walk up to the ItemsControl and go through its DataContext:

<Button Content="Delete"
        Command="{Binding DataContext.DeleteCommand,
                  RelativeSource={RelativeSource AncestorType={x:Type ItemsControl}}}"
        CommandParameter="{Binding}" />

CommandParameter keeps the plain binding so the clicked item is passed along.

Where it stops working

ElementName also works inside a DataTemplate in WPF, but ties the template to one view.
Inside a ContextMenu or ToolTip, neither RelativeSource nor ElementName reaches the window, because the popup is outside its element tree. Put the parent DataContext in the owner's Tag, then read PlacementTarget.Tag from the menu.

A Japanese version is also available.

Expressing SQL Outer Joins in LINQ — Implementing LeftJoin, RightJoin and Shuffle

s-iguchi09 — Thu, 17 Sep 2026 14:02:53 +0000

.NET 10 adds LeftJoin, RightJoin, and Shuffle to LINQ. On .NET Framework 4.8 you still write a left join as GroupJoin + SelectMany + DefaultIfEmpty, and shuffle with OrderBy(_ => Guid.NewGuid()). Both are easy to get subtly wrong.

This is a short summary. The full article, with the complete polyfill and a net48 vs net10.0 output comparison, is here:
Expressing SQL Outer Joins in LINQ — Implementing LeftJoin, RightJoin and Shuffle

The core of the polyfill

LeftJoin wraps the classic idiom behind the .NET 10 signature, with TInner? marking the side that can be missing:

return outer
    .GroupJoin(inner, outerKeySelector, innerKeySelector, (o, inners) => new { o, inners }, comparer)
    .SelectMany(g => g.inners.DefaultIfEmpty(), (g, i) => resultSelector(g.o, i));

RightJoin pivots the same GroupJoin onto the inner sequence. The whole file sits behind #if !NET10_0_OR_GREATER, so it switches off after migration.

Three things worth knowing

Shuffle is a one-pass Fisher–Yates, not a GUID sort. On .NET Framework, eight threads that each created new Random() at the same moment produced the same order in the measurement. The fix seeds each thread from one locked instance.
It re-shuffles on every enumeration. Call ToArray once if you need a fixed order.
Do not use it on IQueryable<T>. The Enumerable method still binds, so an Entity Framework join silently runs in memory. Keep the GroupJoin form for database queries.

A Japanese version is also available.

Why WPF Validation Errors Are Not Displayed, and Choosing Between IDataErrorInfo and INotifyDataErrorInfo

s-iguchi09 — Mon, 14 Sep 2026 16:54:09 +0000

The required-field check is written, but the TextBox never turns red. Sometimes the check never runs at all. Sometimes it runs, Validation.GetHasError is true, and the screen still shows nothing.

This is a short summary. The full article, with measurements for each case on .NET 10, is here:
Why WPF Validation Errors Are Not Displayed, and Choosing Between IDataErrorInfo and INotifyDataErrorInfo

Start from `Validation.GetHasError`

false: no rule is attached, or the input has not reached the source yet. IDataErrorInfo does nothing until the binding has ValidatesOnDataErrors="True", because that setting is false by default. INotifyDataErrorInfo is the only approach that is on by default. Typed text is checked only when it reaches the source, which for TextBox.Text happens on focus loss.
true, but nothing on screen: the error template has nowhere to draw. A replaced Window template without an AdornerDecorator leaves no adorner layer. Inside a ScrollViewer the layer still exists, so only some fields go silent.
A red border with no message: this is just how the default ErrorTemplate works. It never shows the text.

The fix for the message

Supply your own template:

<ControlTemplate x:Key="FieldErrorTemplate">
    <StackPanel>
        <Border BorderBrush="#D13438" BorderThickness="1">
            <AdornedElementPlaceholder x:Name="Adorned" />
        </Border>
        <TextBlock Foreground="#D13438"
                   Text="{Binding ElementName=Adorned,
                          Path=AdornedElement.(Validation.Errors)/ErrorContent}" />
    </StackPanel>
</ControlTemplate>

Adorners take no layout space, so reserve a bottom margin. For new code where the view model owns validation, the article recommends INotifyDataErrorInfo, and remember to raise ErrorsChanged when an error clears.

A Japanese version is also available.

Fixing the Cross-Thread Exception When Updating an ObservableCollection in WPF

s-iguchi09 — Fri, 11 Sep 2026 16:26:05 +0000

You load data inside Task.Run and call Items.Add(line) on an ObservableCollection<T> bound to a ListBox. It throws NotSupportedException: this type of CollectionView does not support changes to its SourceCollection from a thread other than the Dispatcher thread.

This is a short summary. The full article, with a bound vs unbound comparison and a 5,000-item timing test on .NET 10, is here:
Fixing the Cross-Thread Exception When Updating an ObservableCollection in WPF

The collection is not what throws

The same Add on an unbound collection did not throw. The exception comes from the CollectionView that WPF puts between the collection and the control, which belongs to the UI thread. That does not make the collection thread-safe. It only tells you where the check lives.

Two fixes

Few, occasional updates: move the change onto the UI thread.

dispatcher.Invoke(() => Items.Add(line));

Many, frequent updates: register a lock once on the UI thread, then take that same lock for every access.

BindingOperations.EnableCollectionSynchronization(Items, _lock);
// on the worker
lock (_lock) { Items.Add(line); }

Adding 5,000 items one by one, the Dispatcher.Invoke loop took 992 ms. With the shared lock the loop took 6 ms, and the view had all 5,000 notifications after 64 ms. The UI thread still applies them, just later.

Controls themselves stay UI-thread-only either way.

A Japanese version is also available.

Why a WPF ScrollViewer Does Not Scroll and How to Fix It

s-iguchi09 — Thu, 10 Sep 2026 15:04:56 +0000

You put a ScrollViewer with VerticalScrollBarVisibility="Auto" under a header in a vertical StackPanel, fill it with items, and no scrollbar ever shows up. The list just runs off the bottom of the window.

This is a short summary. The full article, with the measured heights for each parent layout on .NET 10, is here:
Why a WPF ScrollViewer Does Not Scroll and How to Fix It

The parent is the problem

A vertical StackPanel measures its children with unlimited height. The ScrollViewer therefore asks for the full height of its content and never overflows. In the measurement, 800 px of rows inside a 200 px StackPanel gave a viewport of 800 and a ScrollableHeight of 0.

The fix

Give the ScrollViewer a finite height. A star row of a Grid is the usual way:

<Grid>
    <Grid.RowDefinitions>
        <RowDefinition Height="Auto" />
        <RowDefinition Height="*" />
    </Grid.RowDefinitions>
    <TextBlock Text="Header" />
    <ScrollViewer Grid.Row="1" VerticalScrollBarVisibility="Auto">
        <!-- items -->
    </ScrollViewer>
</Grid>

A DockPanel with the ScrollViewer as its last child works too, and so does an explicit Height or MaxHeight.

The same cause breaks ListBox virtualization

A 2,000-item ListBox placed inside an outer ScrollViewer or a StackPanel realized all 2,000 containers, because it was given room for every item. Give the ListBox itself a constrained height instead of wrapping it.

A Japanese version is also available.

Why WPF Style Triggers and DataTriggers Do Not Apply — Dependency Property Value Precedence

s-iguchi09 — Wed, 09 Sep 2026 14:13:42 +0000

A DataTrigger in Style.Triggers should turn a Border pink when HasError is true. The binding resolves, the Output window is clean, and the background stays white. The trigger did fire. Its value simply lost to another one.

This is a short summary. The full article, with BaseValueSource readings for each case on .NET 10, is here:
Why WPF Style Triggers and DataTriggers Do Not Apply — Dependency Property Value Precedence

The cause: a local value

Background="White" written on the element is a local value. Local values outrank style triggers, and style triggers outrank style setters. DependencyPropertyHelper.GetValueSource reports Local on the broken element. Note that {Binding ...} or {DynamicResource ...} written on the element is also a local value.

The fix

Move the default out of the element and into the style:

<Style x:Key="StatusBox" TargetType="Border">
    <Setter Property="Background" Value="White" />
    <Style.Triggers>
        <DataTrigger Binding="{Binding HasError}" Value="True">
            <Setter Property="Background" Value="#FFD4D4" />
        </DataTrigger>
    </Style.Triggers>
</Style>

From code-behind

border.Background = ... creates a local value and blocks the trigger again.
SetCurrentValue changes the value without creating one, but it does not remove a local value that is already there.
ClearValue removes it, along with any binding on that property.

The full article also covers theme triggers that a local Foreground silently disables.

A Japanese version is also available.

Controls with Custom Styles Fall Back to the Old Look Under the WPF Fluent Theme

s-iguchi09 — Tue, 08 Sep 2026 16:14:33 +0000

You set ThemeMode="Light" in App.xaml, and check boxes turn Fluent while every Button keeps square corners and a grey background. The only suspect is a <Style TargetType="Button"> that sets nothing but Padding. There is no error and no warning.

This is a short summary. The full article, with a table of style placements measured on .NET 9 and .NET 10, is here:
Controls with Custom Styles Fall Back to the Old Look Under the WPF Fluent Theme

Why one setter drops the whole theme

Older themes such as Aero2 come in as the theme style, which still supplies the template under your own style. Fluent comes in differently: ThemeMode merges a resource dictionary of implicit styles keyed by type. Your {x:Type Button} style has the same key and wins, so the Fluent template is never used. Style="{x:Null}" gives the same legacy look.

The fix, and the trap inside it

Inherit Fluent with BasedOn="{StaticResource {x:Type Button}}". Written directly in Application.Resources, though, it silently resolves to null. In the measurements, that happened whenever the referenced key equals the style's own key and also exists in a dictionary merged into the one declaring the style.

The layout that worked:

Set ThemeMode on Application, not on a Window.
Move the style into its own Styles.xaml and merge that file from App.xaml.
Do not merge Fluent.xaml inside that file.

<Style TargetType="Button" BasedOn="{StaticResource {x:Type Button}}">
    <Setter Property="Padding" Value="16,6" />
</Style>

Check the result by eye. A non-null BasedOn can still point at the old theme.

A Japanese version is also available.

DEV Community: s-iguchi09

Why a WPF DataGrid Edit Does Not Reach the ViewModel When Save Is Clicked, and How to Use CommitEdit

Three things get in the way

The fix

Binding to a WPF UserControl's Own Dependency Property from Inside the Control

Why it happens

The fix in one line

What to avoid

Fixing a RelayCommand Whose CanExecute Does Not Update the Button State in WPF

What the measurements show

The fix

Related Articles

Why WPF Input Limits Such as MaxLength Do Not Apply to Values Set from Code or Bindings

What the measurements show

The fix

Related Articles

Binding to the Parent DataContext from Inside a WPF DataTemplate

Why nothing looks wrong

The fix

Where it stops working

Related Articles

Expressing SQL Outer Joins in LINQ — Implementing LeftJoin, RightJoin and Shuffle

The core of the polyfill

Three things worth knowing

Related Articles

Why WPF Validation Errors Are Not Displayed, and Choosing Between IDataErrorInfo and INotifyDataErrorInfo

Start from Validation.GetHasError

The fix for the message

Related Articles

Fixing the Cross-Thread Exception When Updating an ObservableCollection in WPF

The collection is not what throws

Two fixes

Related Articles

Why a WPF ScrollViewer Does Not Scroll and How to Fix It

The parent is the problem

The fix

The same cause breaks ListBox virtualization

Related Articles

Why WPF Style Triggers and DataTriggers Do Not Apply — Dependency Property Value Precedence

The cause: a local value

The fix

From code-behind

Related Articles

Controls with Custom Styles Fall Back to the Old Look Under the WPF Fluent Theme

Why one setter drops the whole theme

The fix, and the trap inside it

Related Articles

Start from `Validation.GetHasError`