Skip to content
This repository has been archived by the owner on Jul 20, 2019. It is now read-only.

Allow settings panes to derive from SettingsFlyout #57

Closed
Andy-Wilkinson opened this issue Nov 5, 2014 · 3 comments
Closed

Allow settings panes to derive from SettingsFlyout #57

Andy-Wilkinson opened this issue Nov 5, 2014 · 3 comments
Assignees
Milestone

Comments

@Andy-Wilkinson
Copy link
Member

A user has requested that they would like to be able to derive their settings panes from SettingsFlyout (so that the Visual Studio designer shows the settings pane in context). Currently this results in the Okra App Framework embedding the user's SettingsFlyout inside the Okra created SettingsFlyout. It is proposed that Okra should not create its own flyout in this case.

@Andy-Wilkinson Andy-Wilkinson self-assigned this Nov 5, 2014
@Andy-Wilkinson Andy-Wilkinson added this to the v1.0.0 milestone Nov 5, 2014
@Andy-Wilkinson
Copy link
Member Author

Really like the idea of being able to derive from SettingsFlyout - this would be the ideal solution for development with the Visual Studio designer.

The issue is that multi-page settings panes would result in the settings flyout animations when navigating between pages.

Solutions would be,

  • Only support inheriting from SettingsFlyout for single page settings panes - for multi-page panes you would have to use the current method.
  • Support multi-page settings panes, but have the incorrect fly out/in on page changed.
  • Strip out the content from the SettingsFlyout and inject it into Okra's own flyout - this would solve the animation issue, but be a bit of a hack and would probably be incompatible with code-behind.

@Andy-Wilkinson
Copy link
Member Author

As a starting point for the Okra App Framework v1.0 I aim to implement the first point above (only support inheriting from SettingsFlyout for single page settings panes). If attempts are made at navigation then an exception will be thrown, and the alternative approach (settings pages not derived from SettingsFlyout) should be used.

This will allow most use-cases (typically single page settings panes) to derive from SettingsFlyout, whilst minimising any breaking changes if a more complete implementation is introduced in a future release.

@Andy-Wilkinson
Copy link
Member Author

Have managed to identify a way of allowing full support (including multi-page) for SettingsFlyout derived settings panes. This will be the approach used in the next update.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

1 participant