Swapped xBind template ContentControl to ContentPresenter

[Avid29]

@Arlodotexe This is in response to our conversation last night on why a ContentControl was used instead of a ContentPresenter in the x:Bind template.

I tried swapping it out, and it works with no issues.

I also am beginning to remember that the reason we used a ContentControl in Strix has something to do with VisualStates or StateTriggers or something like that, none of which is present in this project template.

I also found more info on how the UserControl is different from the Control or ContentControl. It appears the UserControl is basically a ContentControl with no templating. Therefore, it has a Content property, but its type is UIElement, not object.

Anyway, here's a PR that reduces the visual tree depth of the x:Bind template by directly using a ContentPresenter in the ControlTemplate rather than a ContentControl which will simply wrap a ContentPresenter.

[Arlodotexe]

This is on me and @Avid29 for not documenting the many struggles and iterations it took to put together an x:Bind-ready template without platform guidance in the original project that this template setup was pulled from.

@Avid29 If you search for ContentControl and ContentPresenter in that original codebase, you'll find that none of our custom controls with backed resource dictionary are using ContentPresenter, they're all using ContentControl.

There's presumably good reason for such consistency, and it's consistency I wouldn't have expected if you really could arbitrarily swap them without side effects.

Before a PR like this can happen, a few crucial questions need to be answered:

• What does the platform intend these objects to be?
  • We know ContentControl has a hardcoded visual tree crawl for ContentPresenter to wrap it with a control lifecycle,
  • but is ContentPresenter used elsewhere outside of ContentControl?
• What/where are the overlap/similarities and overhang/differences between ContentPresenter and ContentControl?
• Based on the differences, similarities, and platform guidance, why or why not use one over the other?
• What XAML features might stop working if we made this change?
  • Do visual states still work?
  • Does binding still work?

We need to be certain about these things before making changes. For most of these, it means checking for ourselves.

Rather than doing this in PR, we should continue this investigation in a GitHub issue, a Discord thread, or both.

[Avid29]

@Arlodotexe My apologies. This was a simple change, so I went and made a branch with it. Though I should have put the PR body in a discussion or Discord #community-toolkit thread before opening a PR.