Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SettingsExpander - Provide a simple default DataTemplate #199

Closed
RobertK66 opened this issue Aug 29, 2023 · 3 comments
Closed

SettingsExpander - Provide a simple default DataTemplate #199

RobertK66 opened this issue Aug 29, 2023 · 3 comments

Comments

@RobertK66
Copy link

RobertK66 commented Aug 29, 2023

As mentioned here #191 (comment) providing a default DataTemplate in the SettingsExpander.xaml would enhance usability of the toolkit.

I run into problems when I bound the ItemsSource of the SettingsExpander to an ObservableCollection<Strings> (as newbie in WinUI3 I did not bother about providing my own Template in the XAML). In Visual Studio debugging everything looked alright, but the installed application crashed with "Error 0xc000027b". The simple addition of:

...
<Setter Property="ItemTemplate">
    <Setter.Value>
        <DataTemplate>
            <local:SettingsCard Header="{Binding}" />
        </DataTemplate>
    </Setter.Value>
</Setter>
...

would lead to an Settings Expander always using SettingCards as Items and showing the .ToString() result of whatever classes are bound to the ItemsSource.

I manually tested the above for the WinUI3 Head sample. Not sure if this works for all targets and how to test it thoroughly ...

@niels9001
Copy link
Collaborator

@RobertK66 You should be able to debug/test this by selecting and launching the individual heads. See SettingsControls.Uwp, SettingsControls.Wasm and SettingsControls.WinAppSdk.

Example:
image

@michael-hawker I know you did some magic to render the cards as Items and selecting the correct styles.. would this proposal interfere with that? Thoughts?

@RobertK66
Copy link
Author

What I did to get it to that point is:

  • opened a developer command line tool from my VS2022
  • cloned the repos with the git clone --recurse-submodules https://github.com/CommunityToolkit/Windows.git (into a short local path 😉 )
  • found the subdirectory Windows\components\SettingsControls
  • called the OpenSollution.bat (.. shows 2 warnings about some duplicated imports but in the end a green 'success' )
  • When the VS2022 tried to open the solution I got errors about smthng around "...SDK for core 5.0 is missing ..."
  • used VS Installer to install the unsupported 5.0 runtime (did not help) installed the UWP workload (this did help 😉 a little )
  • I reopened solution and marked the SettingsControl.WinAppSdk as Starting project -> was able to start it with Configuration "Local machine (packaged)" -> Tested my changes there.

I am not able to start the SettingsControl.Uwp project the same way. -> It opens a Window with Logo and then stops with an FileLoadException. Even when I reversed all changes I made to the files locally...
Maybe some dependencies are missing in my VS configuration!?

image

I also tried to run the Unit test. The Tests.WinAppSdk project runs and succeeds all 18 tests. The UWP does not run (with this in log: Could not determine target device configuration. Exception: System.Runtime.InteropServices.COMException (0x80020009) )

i am completely unfamiliar with UWP and multi target development so now i am stuck ...

@michael-hawker
Copy link
Member

The UWP project for SettingsControls has issues due to #169 - as we started pulling things in to use in our app it kind of broke the old UWP project system, we haven't figured out a better way to resolve this yet more automatically with our setup, it hasn't been a priority for our release yet as it only effects local development.

If you open the entire toolkit with the GenerateAllSolution in the root, then it should work?


As for the suggestion, it's non-standard to provide a default template. Looking to NavigationView as the example as it kind of setup this new pattern for Items Controls. You're usually not just binding to a simple collection of strings, but a more complex object which needs mapping of various properties.

There's no controls that provide anything like this out-of-the-box (in OS or WinUI), and it's not something we've ever done before, so I'm not sure what ramifications there may be. It's an interesting suggestion, but given that we provide examples for this scenario in the samples/docs... I'm not sure how useful this edge case may be without precedence elsewhere. Especially given how close we are to our stable release for this type of change of a default value.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants