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

Storyboard animation is preventing a bounded prop to be changed until manually stopped #10110

Closed
FrozDark opened this issue Oct 11, 2022 · 2 comments
Labels
difficulty/tbd Categorizes an issue for which the difficulty level needs to be defined. kind/bug Something isn't working project/animations 🎡 Categorizes an issue or PR as relevant to animations

Comments

@FrozDark
Copy link

FrozDark commented Oct 11, 2022

Current behavior

When you start a storyboard animation the Completed event fires but the state of animation doesn't change and it blocks the property it bind to from changing until you manually call Stop on storyboard

        someStoryboard.Completed += Animation_Completed;

        private void Animation_Completed(object sender, object e)
        {
            System.Diagnostics.Debug.WriteLine($"Animation_Completed");
            if (someStoryboard.GetCurrentState() != ClockState.Stopped)
            {
                someStoryboard.Stop();
                System.Diagnostics.Debug.WriteLine($"Manual stop animation");
            }
        }

Results in "Animation_Completed", "Manual stop animation" in the debug output

Expected behavior

Really stopped animation

How to reproduce it (as minimally and precisely as possible)

  1. Create storyboard animation
  2. Run
  3. Check out the state in the Completed event

Workaround

Call Stop() on completed event

Works on UWP/WinUI

Yes

Environment

Uno.WinUI / Uno.WinUI.WebAssembly / Uno.WinUI.Skia

NuGet package version(s)

Tested on 4.6.0-dev.576

Affected platforms

Skia (GTK on Linux/macOS/Windows)

IDE

Visual Studio 2022

IDE version

No response

Relevant plugins

No response

Anything else we need to know?

Tested on GTK, But I think it's affected on all Uno platforms

@FrozDark FrozDark added difficulty/tbd Categorizes an issue for which the difficulty level needs to be defined. kind/bug Something isn't working triage/untriaged Indicates an issue requires triaging or verification labels Oct 11, 2022
@FrozDark
Copy link
Author

Seems like it works the same way as in WinUI (state is not stopped at completed event). But in uno if I don't manually call Stop on storyboard I can not change the property of an element it references to it just blocks it from changing

@jeromelaban jeromelaban added project/animations 🎡 Categorizes an issue or PR as relevant to animations and removed triage/untriaged Indicates an issue requires triaging or verification labels Oct 11, 2022
@FrozDark FrozDark changed the title Storyboard animation doesn't actually stop Storyboard animation is preventing a bounded prop to be changed until manually stopped Oct 26, 2022
@Xiaoy312
Copy link
Contributor

It is normal that the Storyboard::GetCurrentState() is not ClockState.Stopped when Timeline::Completed occurs. Because by default the Timeline::FillBehavior is HoldEnd, which allow the animated value to "stay" after the animation is completed and the timeline will be in a ClockState.Filling state on completion.
This is exactly the behavior we are getting from windows, so there is nothing to change here.

Now onto the 2nd part:
> When you start a storyboard animation the Completed event fires [...] and it blocks the property it bind to from changing [...]
Yes, this was an old issue in uno:
#631 We cannot change the value of a DependencyProperty which has been animated
which was fixed recently.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
difficulty/tbd Categorizes an issue for which the difficulty level needs to be defined. kind/bug Something isn't working project/animations 🎡 Categorizes an issue or PR as relevant to animations
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants