-
Notifications
You must be signed in to change notification settings - Fork 80
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
Porting Segmented #157
Porting Segmented #157
Conversation
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...? |
No description provided.