fix: Unloading progressring when loaded

[nickrandolph]

GitHub Issue (If applicable): #

PR Type

What kind of change does this PR introduce?

What is the current behavior?

What is the new behavior?

PR Checklist

Please check if your PR fulfills the following requirements:

• Tested code with current supported SDKs
• Tested the changes where applicable:
  • UWP
  • WinUI
  • iOS
  • Android
  • WASM
  • MacOS
• Updated the documentation as needed:
  • General Doc Update
  • Controls Doc Update
  • Extensions Doc Update
  • controls-styles.md
  • lightweight-styling.md (LightWeight Styling Resource Keys)
• Runtime Tests and/or UI Tests for the changes have been added (for bug fixes / features) (if applicable)
• Contains NO breaking changes
• Associated with an issue (GitHub or internal)
• Commits must be following the Conventional Commits specification.

Other information

Internal Issue (If applicable):

[nickrandolph]

@Xiaoy312 @jeromelaban @Youssef1313 @kazo0 would really appreciate some input here. The only way that I've found of unloading the progressring is to set the LoadingContentTemplate to an empty template. The current code (a bit hacky) grabs a local copy of the LoadingContentTemplate so that it can be re-set when the control goes back to the Loading state. Any suggestions on a nicer approach?

[Xiaoy312]

I think you can remove the #LoadingContentPresenter from its parent on "Loaded", and then re-add it if it goes back to "Loading". Its content might need to be remove as well, to avoid unnecessarily proc'ing the template resolution & materialization, since the content is still bound to a possibly changing source LoadingContent.

[jeromelaban]

Should those be reset if the original values change?

[nickrandolph]

yes, and there's probably a bit more refactoring to do. At this stage I just wanted to gauge whether or not there's a better approach before finalising this

[dr1rrb]

Those are private fields, and are not "place holder" but only some "cache" or "backing field". There nothing to reset IMHO.

[nickrandolph]

I think you can remove the #LoadingContentPresenter from its parent on "Loaded", and then re-add it if it goes back to "Loading". Its content might need to be remove as well, to avoid unnecessarily proc'ing the template resolution & materialization, since the content is still bound to a possibly changing source LoadingContent.

Will this break the visual states though?

[dr1rrb]

Those are private fields, and are not "place holder" but only some "cache" or "backing field". There nothing to reset IMHO.

[dr1rrb]

If the user changed the LoadingContentTemplate or the LoadingContentTemplateSelector while the view is "Loaded" they are going to be overwritten.

[Xiaoy312]

@nickrandolph lets start a thread here, so we can keep the discussion in the same place.

I think you can remove the #LoadingContentPresenter from its parent on "Loaded", and then re-add it if it goes back to "Loading". Its content might need to be remove as well, to avoid unnecessarily proc'ing the template resolution & materialization, since the content is still bound to a possibly changing source LoadingContent.

Will this break the visual states though?

It will if you kept them. But with this approach, you will be dropping the #LoadingContentPresenter setters, to handle it in the code-behind.

[dr1rrb]

@Xiaoy312 @jeromelaban @Youssef1313 @kazo0 would really appreciate some input here. The only way that I've found of unloading the progressring is to set the LoadingContentTemplate to an empty template. The current code (a bit hacky) grabs a local copy of the LoadingContentTemplate so that it can be re-set when the control goes back to the Loading state. Any suggestions on a nicer approach?

By the time I did a behavior that was walking the visual tree to determine if any parent was Actual<Width|Height>=0, Visibility.Collapsed, Opacity = 0, render transformed our of the viewport. The issue is that it has to poll the visual tree (only when animating) as we don't have any callback for parent's visibility / opacity.

Thinking about it, we now have a much better approach : the EffectiveViewportChanged event! https://learn.microsoft.com/en-us/uwp/api/windows.ui.xaml.frameworkelement.effectiveviewportchanged?view=winrt-22621

It has the down side that application dev will have to think about it, but the advantage to be usable not only in the LoadingView .

[nickrandolph]

@Xiaoy312 @jeromelaban @Youssef1313 @kazo0 would really appreciate some input here. The only way that I've found of unloading the progressring is to set the LoadingContentTemplate to an empty template. The current code (a bit hacky) grabs a local copy of the LoadingContentTemplate so that it can be re-set when the control goes back to the Loading state. Any suggestions on a nicer approach?

By the time I did a behavior that was walking the visual tree to determine if any parent was Actual<Width|Height>=0, Visibility.Collapsed, Opacity = 0, render transformed our of the viewport. The issue is that it has to poll the visual tree (only when animating) as we don't have any callback for parent's visibility / opacity.

Thinking about it, we now have a much better approach : the EffectiveViewportChanged event!

It has the down side that application dev will have to think about it, but the advantage to be usable not only in the LoadingView .

How would we use the EffectiveViewportChanged event? I'm not sure I follow how this would work

[dr1rrb]

How would we use the EffectiveViewportChanged event? I'm not sure I follow how this would work

This gives you the rectangle that is currently visible for any FrameworkElement. We can create a behavior (or directly package it in the ProgressRing if windows does something similar) that will just stop the animation if the viewport is 0. It should be the case as soon as a parent is Visibility=Collapsed for instance.

[nickrandolph]

Replaced by #1002