Changing LayoutMaster of a each item

Hey guys!

I have a List (ScrollView + Each block). What I want to achieve is, that when I tap on an item it should ‘pop’ out and animate to an Alert where the user can see detail information about that item.

To achieve a nice animation I thought it would be the best to change that items LayoutMaster to another Panel that sits on top of the view hierarchy and animate everything with a LayoutAnimation. The ‘popping’ out part works as expected but when I change that items LayoutMaster back to an item holder Panel which is inside the Each block the layout gets destroyed. It seems that the bounds of the item holder are not recalculated when the item “comes back”.

Hard to describe… so here is a video: https://www.youtube.com/watch?v=jqRKRa7432U

And here is my code so far: https://gist.github.com/jsbeckr/c302c840a1447b5aba758634ee8745e6

Am I doing something wrong? Or is LayoutMaster not supposed to work with UX inside of an Each block? Thanks for your help. :slight_smile:

Hi!

Interesting. Not really sure why this happens from glancing at the code. It’s currently weekend here but we’ll get some eyes on this early next week.

The issue relates to how ItemHolder is being used.

Don’t use Height="100%" inside a StackPanel. Since there is no height defined yet this value won’t do what you want, and can interfere with the layout of the children. Just remove that bit.

In your StateGroup you are using Set values. This is generally not correct and you should be using Change animators instead. This is important since you are only going to change the LayoutMaster in the DialogState. This will allow it to go back to null when not in the DialogState.

The reason you’re getting a 0-size now is because an item with a LayoutMaster doesn’t have a size of it’s own. The ItemHolder as a result has no size when you swtich back, since it’s children have no size, and it has no size of its own.

Note, if you are only switching between states it’s better to just use a WhileTrue instead of a StateGroup. You set the target properties that way you want in the rest state, and then only Change them in the active state. Something like this:

<WhileTrue ux:Name="TaskStates">
        <Change TaskDialog.Opacity="1" />
        <Change TaskDialog.HitTestMode="LocalVisualAndChildren" />
        <Change TaskItem.LayoutMaster="TaskDialog" />
</WhileTrue>

Then do <Set TaskStates.Value="true"/> in your Clicked handler.

Thanks for your help edA-qa mort-ora-y. And especially for explaining why things happen the way they do. Popping in and out works now as expected. :slight_smile:

Sadly there is another problem now. It seems the TaskItem stays in the ScrollView somehow. The LayoutMaster change doesn’t affect the ZOffset of the item and it’s also still scrollable.

This video demonstrates the issue: https://www.youtube.com/watch?v=axohQbBWgwA

The teal square indicates the TaskDialog (new LayoutMaster) of the item. As you can see the item gets clipped through the translucent New Task item above the ScrollView and I can still scroll it.

Thanks again for the help.

It is correct that TaskItem “stays” where it is. LayoutMastser does not change the UI structure, it only says from where the layout information comes.

In the dialog view you can disable the scrolling: <Change theScrollView.UserScroll="false"/>

The ZOffset can also be modified for the active item, to bring it to the top. <Change activeItem.ZOffset="1"/>. Note however this only brings it to the top of it’s immediate parent. You’ll need to chose the item that is the immediately child of the StackPanel inside your ScrollView. If if needs to appear above something outside the ScrollView then the ScrollView itself must be on top.

If there’s not way to structure it to get the item on top we need to take a different approach using AlternateRoot. This allows you to construct an item in an arbitrary location in the UI tree. This sample creates a modal dialog (full-screen) with AlternateRoot: https://github.com/fusetools/fuse-samples/tree/master/Samples/UIStructure/Modal

The AlternateRoot approach is more flexible, but it’s a bit harder to get a transition animation – as you’re really just creating to unrelated elements sharing the same data. If this approach seems like it’d be better for you do it, and we can then work to get the transition correct.

Ahhh awesome! I will try the AlternateRoot route. :smiley: I will answer once I have done that. Thanks again for your help!