A part of the .NET Framework that provides a unified programming model for building line-of-business desktop applications on Windows.
Hello @RogerSchlueter-7899
Thank you for your patience. I was able to reproduce the same binding error in a minimal WPF project:
System.Windows.Data Error: 40 : BindingExpression path error:
'CategoryID' property not found on 'object' ''String' (...)'.
BindingExpression:Path=CategoryID;
DataItem='String';
target element is 'ComboBox' (Name='cbxCategories');
target property is 'SelectedValue'
I reproduced it using the same relevant XAML:
<ComboBox x:Name="cbxCategories"
Width="300"
HorizontalAlignment="Left"
DataContext="CurrentTransaction/Details.DefaultView"
DisplayMemberPath="Name"
SelectedValuePath="CategoryID"
SelectedValue="{Binding Path=CategoryID,
diag:PresentationTraceSources.TraceLevel=High}" />
The issue is indeed caused by this assignment:
DataContext="CurrentTransaction/Details.DefaultView"
This does not create a WPF binding. It assigns the literal string "CurrentTransaction/Details.DefaultView" to the DataContext property of the ComboBox.
In XAML, a binding must be declared through the {Binding ...} markup extension (or its equivalent object-element syntax). Without a markup extension, an attribute value is generally processed as a literal string or converted from a string to the target property type. This behavior is described in the Microsoft documentation:
The high-level binding trace confirms the actual runtime source:
Activate with root item 'CurrentTransaction/Details.DefaultView'
At level 0 - for String.CategoryID found accessor <null>
Therefore, this binding:
SelectedValue="{Binding Path=CategoryID}"
is effectively asking WPF to find a CategoryID property on a System.String. Since System.String has no such property, WPF reports:
DataItem='String'
String.CategoryID found accessor <null>
There is also a separate issue with the suggested path:
{Binding CurrentTransaction/Details.DefaultView}
CurrentTransaction and Details are sibling properties of the Transactions object; Details is not a property of CurrentTransaction.
In addition, / does not mean normal property traversal in a WPF binding path. Microsoft documents / as collection-view current-item syntax. Normal property traversal uses a period (.), while / refers to the current item of a collection view.
For example, Microsoft documents Path=/ as binding to the current item of a collection view. Therefore, simply changing the original value to:
DataContext="{Binding CurrentTransaction/Details.DefaultView}"
does not correctly express the relationship between the two sibling properties and does not provide the category rows to the ComboBox through its ItemsSource.
Assuming the Window.DataContext is an instance of Transactions, the corrected binding is:
<ComboBox x:Name="cbxCategories"
ItemsSource="{Binding Details.DefaultView}"
DisplayMemberPath="Name"
HorizontalAlignment="Stretch"
Margin="0,0,5,4"
SelectedValuePath="CategoryID"
SelectedValue="{Binding CurrentTransaction.CategoryID,
Mode=TwoWay}" />
Each binding property has a distinct role:
-
ItemsSource="{Binding Details.DefaultView}"supplies the category rows from theDetailstable. -
DisplayMemberPath="Name"displays theNamecolumn for each row. -
SelectedValuePath="CategoryID"tells theComboBoxto use the selected row'sCategoryIDas itsSelectedValue. -
SelectedValue="{Binding CurrentTransaction.CategoryID, Mode=TwoWay}"reads the initial category from the current transaction and writes a newly selected category back to it.
In the reproduced example, CurrentTransaction.CategoryID is initially 2, so the ComboBox correctly selects the row whose CategoryID is 2, which is Transport. Changing the selection also updates CurrentTransaction.CategoryID because the SelectedValue binding is two-way.
The earlier AI suggestion did not work because it still used CurrentTransaction/Details.DefaultView as one path, even though CurrentTransaction and Details are sibling properties, and it assigned the supposed list source to DataContext instead of ItemsSource. In WPF, / refers to the current item of a collection view; it is not a general replacement for normal property traversal.
Thank you again for your patience. Please let me know if the actual Transaction class or the DataTable setup differs from this structure.
If my explanation and the information I provided were helpful, I would greatly appreciate it if you could follow the instruction here so others experiencing similar behavior can benefit from it as well.