You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Bug report (I searched for similar issues and did not find one)
Current behavior
The liberal use of internal in DataGridColumn make it impossible to make a 3rd party subclass of anything connected to that class. This leads to compile-time errors like "CS0103 OwningGrid does not exist in the current context" from the subclass.
These properties should be made protected to allow access to subclass creators.
Also, there is a propensity of calling private methods from protected methods that can be overriden, and this causes another maintenance problem, because what should be a one or two method override subclass becomes a nightmare copy/paste job in order to "get at" all the private state and "helpers" that should be protected so subclasses may reuse them too.
Expected behavior
It should be straightforward to make subclasses of DataGridColumn that leverage their implementation to reduce duplicate code or complete rewrites due to inaccessibility.
Minimal reproduction of the problem with instructions
Make a solution for UWP.
Install the packages for Toolkit.
Make a subclass of DataGridComboBox (see below for sample code).
Override the GenerateEditingElement() method.
Attempt to use any of the "helper" methods that would be necessary for a subclass to use, because they access private state in the superclass. For example EnsureColumnBinding(). Or attempt to access the OwnerGrid property, which seems necessary for any subclass of DataGridColumn to access, not just the privileged ones in the same assembly.
Fail due to compiler errors.
Here is a minimal example subclass that fails.
public class EntityComboBoxColumn : DataGridComboBoxColumn {
protected override FrameworkElement GenerateEditingElement(DataGridCell cell, object dataItem) {
EnsureColumnBinding(dataItem);
EnsureDisplayMemberPathExists();
EnsureItemsSourceBinding();
var comboBox = new ComboBox {
Margin = default(Thickness),
HorizontalAlignment = HorizontalAlignment.Stretch,
VerticalAlignment = VerticalAlignment.Center
};
return comboBox;
}
}
Environment
Since this is a design issue, it appears in all versions of everything. It's nice to have open source everything, but it's also nice to have open subclassing too!
Nuget Package(s): All
Package Version(s): All
Windows 10 Build Number:
- [ x] Fall Creators Update (16299)
- [ ] April 2018 Update (17134)
- [ ] October 2018 Update (17763)
- [ ] Insider Build (build number: )
App min and target version:
- [x ] Fall Creators Update (16299)
- [ ] April 2018 Update (17134)
- [ ] October 2018 Update (17763)
- [ ] Insider Build (xxxxx)
Device form factor:
- [x ] Desktop
- [ ] Mobile
- [ ] Xbox
- [ ] Surface Hub
- [ ] IoT
Visual Studio
- [ x] 2017 (version: )
- [ ] 2017 Preview (version: )
The text was updated successfully, but these errors were encountered:
We are not adding features to this DataGrid at this time. If you would like to see this feature in the newly proposed WinUI DataGrid, please add a comment in the WinUI discussion issue. Thanks!
I'm submitting a...
Bug report (I searched for similar issues and did not find one)
Current behavior
The liberal use of internal in DataGridColumn make it impossible to make a 3rd party subclass of anything connected to that class. This leads to compile-time errors like "CS0103 OwningGrid does not exist in the current context" from the subclass.
These properties should be made protected to allow access to subclass creators.
Also, there is a propensity of calling private methods from protected methods that can be overriden, and this causes another maintenance problem, because what should be a one or two method override subclass becomes a nightmare copy/paste job in order to "get at" all the private state and "helpers" that should be protected so subclasses may reuse them too.
Expected behavior
It should be straightforward to make subclasses of DataGridColumn that leverage their implementation to reduce duplicate code or complete rewrites due to inaccessibility.
Minimal reproduction of the problem with instructions
Here is a minimal example subclass that fails.
Environment
Since this is a design issue, it appears in all versions of everything. It's nice to have open source everything, but it's also nice to have open subclassing too!
The text was updated successfully, but these errors were encountered: