Allow TextSearch.TextBinding on non-controls.#20884
Conversation
Allow setting `TextSearch.TextBinding` on non-controls: in particular I would like to be able to set it on (tree) data grid columns. For example:
```
<TreeDataGrid>
<TreeDataGridTemplateColumn TextSearch.TextBinding="{Binding Foo}">
<DataTemplate>
<TextBlock Text="{Binding Foo}"/>
</DataTemplate>
</TreeDataGridTemplateColumn>
</TreeDataGrid>
```
grokys
added
needs-api-review
There was a problem hiding this comment.
Pull request overview
Expands the TextSearch.TextBinding attached property so it can be set on non-Interactive objects (e.g., column definitions), enabling consumers to surface text-search metadata on non-control elements that still participate in generating interactive UI.
Changes:
- Broaden
TextSearch.TextBindingPropertyregistration target fromInteractivetoAvaloniaObject. - Update
GetTextBinding/SetTextBindingAPIs and XML docs to acceptAvaloniaObject.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
You can also share your feedback on Copilot code review. Take the survey.
|
For consistency, I think the same change should be applied to |
|
/update-api |
|
❌ |
MrJul
added
api-approved
|
/update-api |
|
❌ |
|
You can test this PR using the following package version. |
Yeah I wasn't sure about that. What would be the use-case? |
Sorry, I already made the changes. Mostly for consistency: nothing prevents a user from putting objects derived from |
What does the pull request do?
Allows setting
TextSearch.TextBindingon non-controls: in particular I would like to be able to set it on (tree) data grid columns. For example:What is the current behavior?
The attached property is only intended to be applied to
Interactivecontrols. Data grid columns are not interactive, but they do produce interactive elements.What is the updated/expected behavior with this PR?
Text search bindings can be set on arbitrary elements.
Breaking changes
The
GetTextBinding/SetTextBindingmethods accept a different object type. This is a less specific type and so shouldn't be a source breaking change.