Flyout/Menu/Settings need way better declarative support

[timheuer]

Right now the Flyout bases are really designed to be instantiated from code. This is not ideal for MVVM in all cases as well as doesn't help in designer scenarios.

[jnystrom]

Can we upvote this??? Declarative support is needed BAD.

[timheuer]

While I love the designer, this is lower priority for me actually. The usage patterns of this don't make it ideal to keep these types of things in the visual tree all the time, which is why I had a code-focused approach. That said, I get that there are issues...much related to the use of an internal popup setting itself to the child, which isn't ideal for declarative scenarios.

-th

---

http://timheuer.com/blog/ twitter: @timheuer

On Mon, Jun 18, 2012 at 1:40 PM, jnystrom < reply@reply.github.com

wrote:

Can we upvote this??? Declarative support is needed BAD.

---

Reply to this email directly or view it on GitHub: https://github.com/timheuer/callisto/issues/34#issuecomment-6408331

[jnystrom]

Yeah the issue is when you are talking about larger flyouts, like dealing with account information. Creating that view in code is not fun at all and binding to viewModel data. Wish MS would have supplied this like they did on the JS side, especially when it is the recommended pattern.

[jnystrom]

I am getting around it for now, by declaring a DataTemplate in a resource file and setting the SettingsFlyout.ContentTemplate to the DataTemplate...seems to be a pretty good workaround for now. Thanks for the toolkit!

[timheuer]

In this case I'd recommend using a usercontrol to encapsulate and you could have a good design experience.

-th

Sent from mobile - please excuse tone and brevity

On Jun 18, 2012, at 5:27 PM, jnystromreply@reply.github.com wrote:

Yeah the issue is when you are talking about larger flyouts, like dealing with account information. Creating that view in code is not fun at all and binding to viewModel data. Wish MS would have supplied this like they did on the JS side, especially when it is the recommended pattern.

---

Reply to this email directly or view it on GitHub: https://github.com/timheuer/callisto/issues/34#issuecomment-6413094

[nickrandolph]

Tim I'm not sure I agree with the usage pattern comment. Whilst I agree this may be true for the settings flyout, if you're trying to present flyouts that are associated with items on the page, or the app bar, you want them to be part of the visual tree so that you can use visual states to manage them. This would also making them fit into the mvvm style of development. Anything that could be done to assist this scenario would be greatly appreciated!

[timheuer]

@nickrandolph How would a flyout be triggered by a visual state?

[nickrandolph]

Surely it's just a matter of setting the IsOpen property to true? I haven't worked with your flyout control much because of the lack of a design experience :-(

To give you an example: at the moment if we want to do flyouts (for example similar to the built in flyout that appears when you pin additional tiles) we create them in Blend as hidden panels (typically Grid) and then simply set the Visibility property to Visible in a visual state when they should be displayed.

[timheuer]

@nickrandolph actually it isn't. In order for the Flyout to ensure it dismisses at the proper times it has to be aware of SizeChanged, WindowActivated events.

The way you are doing your flyouts (visible) means they are in the visual tree when likely not needed (may not be a big deal for most apps but just FYI) and My guess is that your flyouts are not correctly dismissing at the right times as well.

I'm totally with you that I'd love to get this fixed, but haven't found the bullet-proof solution yet to ensure compatibility with existing customers. I can't just break people who are using this and won't change it unless I have a method that keeps customer code working fine but enables better View-based support as well

[nickrandolph]

I get the point about them being in the visual tree - but in our case there is a high probability the user will be opening the flyout so happy to take the hit on that one.

I also agree that you can't just break people who are using your existing code.

I also respect that the flyout needs to be aware of various events in order to ensure it closes at the right time. We've had to add code at the page level that ensures the visual state changes (to dismiss flyout in most cases) based on those events.

With this in mind, what do you suggest in terms of designing the flyouts. I noticed that you suggested using user controls - is this the best way? Also, is there a good tie in with mvvm?

[timheuer]

UserControl as the flyout content would be a good approach. I assume however that ideally you'd want the ViewModel to be the same one as the one that the flyout is being hosted in...this presents a problem.

It really sucks I agree. One of the key challenges is that even in refactoring to make this possible, I need to hook up to things before the item is added to the tree...but OnApplyTemplate doesn't fire until you are added to the tree. Catch-22 for me. I'm still thinking about it and may introduce some massive tree-walk hackery to get this done.

[yorkshirespud]

I'm having a problem getting SettingsFlyout.ContentTemplate to work, any ideas what I'm doing wrong?

If I set .Content to either e.g. a string, or a a TextBlock in code, then that text shows. If however, I set the ContentTemplate to a resourced DataTemplate, I get a blank. Any ideas?

[yorkshirespud]

Please ignore my previous question, I've got it working! It turns out the ContentTemplate was working just fine, but the default settings of SettingsFlyout meant the control was drawing white content on a white background.

I set SettingsFlyout.ContentBackgroundBrush to e.g. a Solid Blue Brush, and the ContentTemplate contents, bound to the Content property appeared just fine.