Porting Segmented #157
Merged
Porting Segmented #157
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Getting an error when running the sample on UWP. Working fine for WASDK and WASM! |
|
The Segmented control tests are also causing issues over on the Labs-Windows repo, so we need to resolve/understand that issue before we bring them over here, though maybe they won't have an issue as we build |
485628c
to
d980525
Compare
|
@Arlodotexe interestingly the original PR passed the build, updating the tooling and will see if these tests fail again the same way. If they don't, then I may suspect it has something to do with the package reference vs. project reference? |
|
Grabbed the full callstack with mixed debugging: I don't even see the segmented control here... With some breakpoints, I see the Saw some other weird exceptions about uri lookups, but think unrelated:
|
|
Tried putting a I then commented out the first 'Basics' sample, and was able to see the |
|
I removed the binding to the <Setter Property="ItemsPanel">
<Setter.Value>
<ItemsPanelTemplate>
<local:EqualPanel Spacing="{ThemeResource SegmentedItemSpacing}" />
</ItemsPanelTemplate>
</Setter.Value>
</Setter>And that then loaded... so that leads back to the Framework Ancestor Extension which is what's jamming up our tests for this same control in the Labs repo... which seems a bit too coincidental... but we didn't have this problem before either... |
|
Not sure if needed but turned on https://learn.microsoft.com/en-us/windows/windows-app-sdk/api/winrt/microsoft.ui.xaml.debugsettings.failfastonerrors (same exists on UWP) and removed the usage of the Had also tried to use |
|
I managed to get this stack trace out of a FastFail (mixed debugging enabled) In this trace, it appears the method In @michael-hawker's trace, it looks like it's failing to convert the XAML type provided to It's still confusing why this only happens in the test app and not the sample app when they share the same codebase. Maybe something about the Sample app compiling with .NET Native? |
|
Thanks @Arlodotexe, that makes it seem like the same root issues we're facing with the tests. Was that from the Labs environment or this specific PR in the sample app? Which I think may be due to a mismatch of versioning between the Extensions NuGet package? As the API changed slightly here with this commit: 0a7b623 Though theoretically in the main repo here everything should work as it should all be source code references... |
|
Will try updating this branch once we get the converters fixes in, while working on Labs fixing that build I did test the Segmented control there on UWP and it was perfectly fine (believe I tested both Debug and Release). So will be confusing if still not working here... would mean something is different between Labs environment and our environment here... which wouldn't make much sense. |
|
Good to see a clean build. Converted back to draft until I validate locally if UWP is working again... if it's not, it's very odd as it was fine in Labs... but could have been due to assembly mismatch we had with extensions still somehow, maybe? |
Also ensure PackageId is setup correctly
|
As far as I can tell, besides the namespace changes, the only difference to the code is that in Labs there was a package reference to the 'Helpers' and in this repo it's just a ProjectReference to the Extensions (was helpers before in either case didn't change anything)... It's really weird that having the direct code reference should make a difference here... |
|
Wonder if it has something to do with built vs. source reference, going to test by building NuGets locally and then trying the segmented package directly in another UWP test app. |
|
I've manually validated with locally built Release mode NuGet packages that when running as a UWP app from a NuGet package that the Segmented control is working fine... Which would explain a bit why it's working in Labs as that's referencing the Extensions package via a NuGet package and not source... Just a very odd issue. Checked in Release mode of the app too (and fine), but this really just feels like some sort of UWP/Compiler/WinUI type bug that we'll want to file... Not sure the best approach for that. Something we can look into later. @niels9001 maybe we can take the WinUI 2+3 template and copy the segmented control and the Framework Extension into there and see if we can get an isolated repo. Though considering this works on WASDK fine without issue then it's probably not something we can expect a fix for. We may just need to make a note somewhere for local development of this control that it has to be done on WASDK or WASM and then checked on UWP as part of a NuGet package build? It does mean that the sample may crash when building the sample app all-up locally as well, but I think we'll be ok...? |
Arlodotexe
approved these changes
Aug 3, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.