locked
Settings Charm example? RRS feed

  • Question

  • I'm writing a simple app to learn all of the new features of Win8 and I would like to make a settings UI that takes some text input from the user that is needed prior to the app functions being enabled (API key, etc).

    I'm having a little trouble working out how this should be done and have tried converting the JS sample from here across to my C# application without any success so far.

    From the docs it seems like I should be able to do something like:

    SettingsPane.GetForCurrentView().ApplicationCommands.Add(new SettingsCommand(KnownSettingsCommand.Preferences, new UICommandInvokedHandler(delegate(IUICommand command)
    {
        //this doesn't ever get hit
    })));
    
    SettingsPane.Show();
    

     

     

    However, the event handler doesn't ever get hit in this circumstance and even if it did get hit, I'm a little unsure how to put my settings UI in there?

     

     

    Monday, September 26, 2011 1:56 AM

Answers

  • @Craig - Are you seeing "Preferences" in the settings dialog?  If you put some simple Debug.WriteLine statements in your command does it work?

    ie.:

    SettingsPane pane = SettingsPane.GetForCurrentView();
    SettingsCommand cmd = new SettingsCommand(KnownSettingsCommand.Preferences, (a) =>
                    {
                        Debug.WriteLine("preferences clicked");
                    });
    pane.ApplicationCommands.Add(cmd);
    

    Putting your UI in there is up to you.  You would listen for this event and add some UI following the UI guidelines (346px or 646px UI).  Take a look at my tips/tricks session where I do an example of this for XAML: http://channel9.msdn.com/Events/BUILD/BUILD2011/TOOL-515T


    Tim Heuer | Program Manager, XAML | http://timheuer.com/blog | @timheuer
    Monday, September 26, 2011 2:21 AM

All replies

  • @Craig - Are you seeing "Preferences" in the settings dialog?  If you put some simple Debug.WriteLine statements in your command does it work?

    ie.:

    SettingsPane pane = SettingsPane.GetForCurrentView();
    SettingsCommand cmd = new SettingsCommand(KnownSettingsCommand.Preferences, (a) =>
                    {
                        Debug.WriteLine("preferences clicked");
                    });
    pane.ApplicationCommands.Add(cmd);
    

    Putting your UI in there is up to you.  You would listen for this event and add some UI following the UI guidelines (346px or 646px UI).  Take a look at my tips/tricks session where I do an example of this for XAML: http://channel9.msdn.com/Events/BUILD/BUILD2011/TOOL-515T


    Tim Heuer | Program Manager, XAML | http://timheuer.com/blog | @timheuer
    Monday, September 26, 2011 2:21 AM
  • Here's hoping a C# sample is made available too.
    http://sqlblog.com/blogs/jamie_thomson/ | @jamiet | About me
    Jamie Thomson
    Monday, September 26, 2011 8:24 AM
  • @Craig - Are you seeing "Preferences" in the settings dialog?  If you put some simple Debug.WriteLine statements in your command does it work?

    ie.:

     

    SettingsPane pane = SettingsPane.GetForCurrentView();
    SettingsCommand cmd = new SettingsCommand(KnownSettingsCommand.Preferences, (a) =>
                    {
                        Debug.WriteLine("preferences clicked");
                    });
    pane.ApplicationCommands.Add(cmd);
    

    Putting your UI in there is up to you.  You would listen for this event and add some UI following the UI guidelines (346px or 646px UI).  Take a look at my tips/tricks session where I do an example of this for XAML: http://channel9.msdn.com/Events/BUILD/BUILD2011/TOOL-515T

     


    Tim Heuer | Program Manager, XAML | http://timheuer.com/blog | @timheuer

    Thanks Tim, I think I see what lead to my initial confusion.

    When I call SettingsPane.Show() immediately after adding the preferences command I don't see a "Preferences" entry in the settings panel. 

    However, when I close that settings pane and then manually swipe it out, the "Preferences" entry is there as expected and the event is hit.

    Do I need to delay before calling SettingsPane.Show()? I'm calling it from within OnLaunched(LaunchActivatedEventArgs args) in App.xaml.cs

     

    Monday, September 26, 2011 2:33 PM
  • @tim: The tips/tricks video you linked was very useful, thank you!

    @jamie: You can take a look at my source for some hints, the project is on GitHub (https://github.com/craigomatic/MetroFlickr) - see MainPage.xaml, MainPage.xaml.cs, Settings.xaml and Settings.xaml.cs


    Monday, September 26, 2011 7:33 PM
  • @jamie: You can take a look at my source for some hints, the project is on GitHub (https://github.com/craigomatic/MetroFlickr) - see MainPage.xaml, MainPage.xaml.cs, Settings.xaml and Settings.xaml.cs

    Excellent, thanks Craig.
    http://sqlblog.com/blogs/jamie_thomson/ | @jamiet | About me
    Jamie Thomson
    Monday, September 26, 2011 8:01 PM
  • One delay way can help you, use Dispatcher.InvokeAsync

     

     

                if (settingsViewRequired)
                {
                    this.Dispatcher.InvokeAsync(Windows.UI.Core.CoreDispatcherPriority.Normal, (s, args) => { SettingsPane.Show(); }, this, null);
                }
                else
                {
                    _RunApp((string)username, (string)apiKey);
                }
    

    Sincerely,


    Bob Bao [MSFT]
    MSDN Community Support | Feedback to us
    Get or Request Code Sample from Microsoft
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Tuesday, September 27, 2011 10:35 AM
  • Having watched the video, it looks like in XAML, there are no special elements for hosting and showing the settings UI. You're basically just creating a bit of UI on top of the rest of your app, and manually showing and writing your own code to handle the light dismiss.

    This seems different from the JavaScript example in the SDK, where you apply a special data-win-control="WinJS.UI.SettingsPane" attribute to the panel, and it appears that the JS stuff for WinRT takes care of showing and hiding it for you.

    I guess there's nothing wrong with doing the work yourself, but one thing worried me slightly - the code for your home-brew light dismiss looked like it was going to run on every single panel touch. Is that right? Also, does this play nicely with accessibility? (I don't even know what the accessible way to dismiss the charms or the settings panel is meant to be.) Does this give me the same behaviour as JS apps if someone happens to switch away from my app and then switch back?..

    It's all those less well troden paths that I worry about with this sort of thing, and wouldn't worry about if I was using some official mechanism like JavaScript seems to get. Are there any plans to either a) give us some similar 'proper' mechanism or b) comprehensively document all the little unusual cases like keyboard dismissal, switching away, proper behaviour on suspend and so on that we need to worry about if doing it ourselves?

    Wednesday, September 28, 2011 2:04 PM
  • @IanG - yes, actually in my sample you are right that that the light dismiss would run on any touch...that's the intent of light dismiss.  If you touch away from any flyout then it dismisses the flyout...regardless of what you were doing.  My sample however would have dismissed the flyout if I clicked in it, which isn't intentional, so bug in my sample :-).

    As you note, WinJS has a specific SettingsPane control.  The core concepts that enable that control are the flyout control and these are things being investigated for XAML.


    Tim Heuer | Program Manager, XAML | http://timheuer.com/blog | @timheuer
    Wednesday, September 28, 2011 5:01 PM
  • Sorry, I should have clarified what I meant when I said "any touch."

    I meant "any touch, including ones you really don't need to handle because the preferences screen is no longer visible."

    (I hadn't actually noticed the bug you mentioned...)

    The Flyout control's JS only too? That's a shame. The big talk about controls a build rather gave the impression that there was an underlying set of controls defined by WinRT that was surfaced to both XAML and JS. Are there in fact two completely separate but similar sets of controls? Or is there some commonality of implementation here?

    Wednesday, September 28, 2011 5:05 PM
  • Tim, I am implementing this as a custom control, but what are the current guidelines for melding into the Charm UI? Should it have the same background color as the settings charm itself? This used to be green but is now dark blue....how do I get that color?
    Saturday, March 3, 2012 11:27 PM
  • @flohwat - I would be sure to look at Popup.IsLightDismissEnabled for your control.  As to the UI -- look at http://design.windows.com -- but basically the typical settings flyout will be a white background with a title area that matches your apps' theme (i.e., the tile background color from your manifest) and implements the light dismiss model.


    Tim Heuer | Program Manager, XAML | http://timheuer.com/blog | @timheuer

    (if my post has answered your question, please consider using the 'mark as answer' feature in the forums to help others)

    Saturday, March 3, 2012 11:33 PM
  • It seems the API has changed in the beta. I cannot find any KnownSettingsCommand.

    I am doing this in the constructor of my base page, the ApplicationCommands.Add line IS hit, adding a SettingsCommand with the "Account" name (it is my container.Name) but this entry does not appear in the settings charm.

    if (Application.Current is IStoreSettings)
        SettingsPane.GetForCurrentView().CommandsRequested += CommandsRequested;
    
     public void CommandsRequested(SettingsPane sender, SettingsPaneCommandsRequestedEventArgs args)
            {
                foreach (var container in ApplicationData.Current.RoamingSettings.Containers.Values)
                    args.Request.ApplicationCommands.Add(new SettingsCommand(1, container.Name, o =>
                    {//some code here }));
            }
    Do you have any ideas?

    Streamlined simplicity

    Monday, March 19, 2012 2:23 PM
  • @tec-goblin - instead of using "1" use a string value:

    if (Application.Current is IStoreSettings)
        SettingsPane.GetForCurrentView().CommandsRequested += CommandsRequested;
    
     public void CommandsRequested(SettingsPane sender, SettingsPaneCommandsRequestedEventArgs args)
            {
                foreach (var container in ApplicationData.Current.RoamingSettings.Containers.Values)
                    args.Request.ApplicationCommands.Add(new SettingsCommand("someValue", container.Name, o =>
                    {//some code here }));
            }

    There is a known issue with a non-string value as the first param.

    Tim Heuer | Program Manager, XAML | http://timheuer.com/blog | @timheuer

    (if my post has answered your question, please consider using the 'mark as answer' feature in the forums to help others)

    Monday, March 19, 2012 2:44 PM
  • Thanks! I changed 1 with "i++.ToString()" and it works :).

    Streamlined simplicity

    Monday, March 19, 2012 2:57 PM
  • Sorry but what namespace is IStoreSettings in?  Bing isn't coming up with much other than this forum topic.
    Thursday, April 12, 2012 5:23 AM
  • It's actually a namespace I made myself. It has one property: SettingsWindow. In this case I know if the App supports Settings or not. (I know that the IStoreSettings is not very good naming-convention-wise, but I couldn't find something better).

    Streamlined simplicity

    Thursday, April 12, 2012 10:29 PM
  • Thanks!  I thought I (or Bing) was losing it.  :-)
    Friday, April 13, 2012 8:56 PM
  • Hi Tim,

    I have watched your Build Tips and Tricks video, which was very helpful, though I seem to be having an issue with ApplicationCommands.

    It seems to be missing a reference, error as follows:

    Error 1 'Windows.UI.ApplicationSettings.SettingsPane' does not contain a definition for 'ApplicationCommands' and no extension method 'ApplicationCommands' accepting a first argument of type 'Windows.UI.ApplicationSettings.SettingsPane' could be found (are you missing a using directive or an assembly reference?)

    I have tried searching for what I am missing, but can't seem to find anything.

    Any guidance would be great.

    Thank,

    Edit:

    Hi Tim,

    I have just found your sample at http://timheuer.com/blog/archive/2012/03/06/creating-custom-settings-pane-xaml-windows-8.aspx which does it in a slightly different way, so I am looking at doing it this way.

    Cheers


    • Edited by B13ella Monday, May 14, 2012 11:53 AM
    Monday, May 14, 2012 11:43 AM
  • @B13ella - lok at the new API which has changed slightly from the developer preview.  Specifically:

    SettingsPane.GetForCurrentView().CommandsRequested += OnCommandsRequested;
    
    void OnCommandsRequested(SettingsPane sender, SettingsPaneCommandsRequestedEventArgs args)
    {
      args.Request.ApplicationCommands // here.
    }


    Tim Heuer | Program Manager, XAML | http://timheuer.com/blog | @timheuer

    (if my post has answered your question, please consider using the 'mark as answer' feature in the forums to help others)

    Monday, May 14, 2012 3:23 PM
  • Thanks Tim,

    I have got that working now.

    Cheers

    Tuesday, May 15, 2012 11:40 AM
  • Hi Tim,

    This thread began in the Build Preview days...

    So are there any strategy changes as of Consumer Preview on how we go about developing the basic settings options for an app in xaml? And is there anywhere current that describes the basic process?

    It looks like the API provides us a way to create links from the initial Settings panel that comes up when the user clicks on the settings charm while in our app.

    It sounds like xaml devs are then on their own to create secondary flyouts triggered by one of the custom links to contain the dropdowns or other controls that actually allow the user to set application settings and to manage things like persisting those values as well as handling styling and behavior issues so that our secondary flyouts play nice with the main settings panel.

    Besides the Windows.UI.ApplicationSettings api where there any new introductions or changes as of the Consumer Preview?
    Is it worth waiting until the RC before spending time on rolling our own settings in our apps to see something more robust and consistent is coming?
    If not, where can we find a good explanation of these issues and the basic patterns we should be following when rolling our own version of app settings in XAML apps?

    Thanks.



    Sunday, May 20, 2012 10:01 PM
  • @DLamb - you should look at using the Popup with IsLightDismissEnabled=false combination to create the experience.  We will not have a <SettingsPanel> control specifically, but there is nothing blocking the scenario.  In fact there are some open source projects that are out there to accomplish this.

    Tim Heuer | Program Manager, XAML | http://timheuer.com/blog | @timheuer

    (if my post has answered your question, please consider using the 'mark as answer' feature in the forums to help others)

    Sunday, May 20, 2012 11:41 PM
  • Thanks Tim,

    I gather you meant to type "IsLightDismissEnabled=true" as opposed to false.

    The more I dig into this, the more it surprises me that XAML developers are not provided a XAML equivalent to the SettingsFlyoutControl that gets prominent mention in the Guidelines for app settings.

    You mention that there is nothing blocking the scenario, but there do seem to be some hurdles.
    The Guidelines mention a few different sizes of flyouts and locations that the main settings pane may appear depending on the system.
    Are there properties somewhere that we can read, set, or bind to that will provide the size and location at runtime? It sounded like you hard coded one of the sizes in your blog write up. This just seems like something that is really prone or really likely to change and does not seem like something that lends itself to hard coding.

    How about the colors used by the main settings pane, are they accessible at runtime or are there some themed system color resources that it uses that we can look up?

    I noticed that your March blog post approaches the issue from a code perspective as opposed to a XAML approach. 
    What is your take or experience with regards to taking a more XAML/Blend based approach to the issue?

    Thanks.

    Wednesday, June 20, 2012 4:38 AM
  • @DLamb - yes I meant true :-)  As to not having a strong-typed control, yes we don't.  Let me address a few things...

    1. different sizes -- it really isn't dependent upon the system, but rather your app.  they are just setting guidelines that there are 2 desired sizes (narrow/wide).  So for those purposes it is either 346 or 646 pixels...nothing the system will tell you as the system doesn't know what you want to put there.
    2. colors - these are the system colors and not available through any API.  This has been a frequent request but it is not available (to any platform, not just XAML).  The guidelines are that you should actually make sure the experiences are easily identified to *your* app and not try to mimic the system for app-specific items.
    3. code approach - yes, very much so.  However, this is my personal preference.  I don't personally think that a Popup needs to be parented :-) (I'm usually the minority here) which is why I have that approach.  My approach allows you to only create the UI when you need and not have anything taint the tree.  You could absolutely have a <Popup> in your page and just set IsOpen on that to show as needed if you want...totally do-able.

    There are some open source projects that are out there to try to alleviate getting the design right and there will be an SDK sample showing the steps if you wanted to roll your own.


    Tim Heuer | Program Manager, XAML | http://timheuer.com/blog | @timheuer

    (if my post has answered your question, please consider using the 'mark as answer' feature in the forums to help others)

    Wednesday, June 20, 2012 4:54 AM
  • Tim,

    regarding your reply to 1.

    I follow that there are two recommend sizes for our custom SettingsFlyouts, one narrow and one wide. It is my impression, please correct me if I am wrong, that the narrow one is the typical size for the main settings pane is it not? If it is, does it stick to this 346 pixel size across all supported resolutions? What about future resolutions? Doesn't this seem like a hard coded value that is destine to fail us at some point in the not too distant future?

    One of the great things about XAML seems to be the ability to create resolution independent app that scale, and hard coding a specific pixel width for a panel like this just seems wrong. :-)

    Wednesday, June 20, 2012 5:41 AM
  • The system uses device independent pixels.  So on a same-sized monitor (say 10.6") at the different scales, yes this will be the same, similar to how the Snapped app space uses 320px space.

    Tim Heuer | Program Manager, XAML | http://timheuer.com/blog | @timheuer

    (if my post has answered your question, please consider using the 'mark as answer' feature in the forums to help others)

    Wednesday, June 20, 2012 6:09 AM
  • And as for the location of the settings pane appearing on the left or right side?
    What is the recommended way of reliably figuring that one out?

    Wednesday, June 20, 2012 2:06 PM
  • @DLamb - I assume you mean for RTL configurations?  Right now there is not an API for determining where the Edge is coming from.  We realize this is an issue for developers (and frankly for even the built-in WinJS SettingsFlyout) and are looking to address this for developers in RTM.

    Tim Heuer | Program Manager, XAML | http://timheuer.com/blog | @timheuer

    (if my post has answered your question, please consider using the 'mark as answer' feature in the forums to help others)

    Wednesday, June 20, 2012 3:22 PM
  • For a complete solution, including the user interface:

    Install CharmFlyout from NuGet.org and add to your existing Metro application:

    1. Install the NuGet Package Manager if you have not already.
    2. Open your Metro application in Visual Studio
    3. Select Manage NuGet Packages from the Project menu.
    4. Click Online. Search for CharmFlyout. Click Install.

    If you have a single page application with a MainPage.xaml, then edit MainPage.xaml to:

    1. Add the using:CharmFlyoutLibrary.
    2. Add the CharmFlyout custom control.
    3. Add content to the CharmFlyout.

    More details here: http://w8isms.blogspot.com/2012/07/charmflyout-another-charming.html


    John Michael Hauck

    Friday, July 20, 2012 6:33 PM
  • @John - good work...however some of the animations and redlines are a little off.  You could also use http://timheuer.com/blog/archive/2012/05/31/introducing-callisto-a-xaml-toolkit-for-metro-apps.aspx

    Tim Heuer | Program Manager, XAML | http://timheuer.com/blog | @timheuer

    (if my post has answered your question, please consider using the 'mark as answer' feature in the forums to help others)

    Friday, July 20, 2012 6:45 PM
  • It is great that a number of folks are contributing controls and libraries to the community!

    After working through the issue in Blend to create secondary settings panes for Setttings, About, Feedback, and Help I have found using the system Popup does work without the need to rely on or include 3rd party dependencies and libraries.

    The RP version of Blend is still pretty buggy, but after I found ways around a few of those bugs, plunking a Popup onto the design surface and laying it out there is pretty straight forward and a fairly clean way to go. I am sure a less buggy version of Blend isn't too far off.

    I haven't found a good source for the redlines that Microsoft uses for their secondary panes yet or that are used in the system settings panes like the "Permissions" pane, so I have been eyeballing it for now. If I can't find a redline, I will eventually get around to reverse engineering screen shots I guess.

    I really hate that the Windows 8 design docs are not available in a downloadable and searchable PDF instead of the not so easy to consume nested web page format that they are currently in... The redline detail information is probably hiding in there somewhere.

    Speaking of the Permissions pane... I don't suppose there is a way for developers to stylize or color the system secondary settings panes so that they match *our* app experience? Perhaps there is some logical design reasoning why a pane like Permissions should be inconsistent and violate the guidance mentioned elsewhere in this thread? 

    " The guidelines are that you should actually make sure the experiences are easily identified to *your* app and not try to mimic the system for app-specific items."

    Are the animations redlined or specified anywhere, after playing around a bit, it looks like setting the main grid in the popup to use an EdgeUIThemeTransition from the right edge and then setting relevant content element items to use an EntranceThemeTransition with a FromHorizontalOffset value of about 80 seems close to what the Permissions pane is using, but that is a quick trial and error approximation, having the actuals of what the animation guidance for these secondary settings panes are would be helpful both for those that want to provide libraries to the community and for those of us that prefer to use the basic controls provided.

    Friday, July 20, 2012 8:03 PM
  • Tim,

    Thanks for pointing out the margin discrepancies. I updated CharmFlyout and the look is now identical (as far as I can tell) with the MSFT supplied Permissions flyout. As for the light-dismiss behavior, CharmFlyout behaves identically to the MSFT Permissions flyout - so I'm not sure what to change in that regard. Any specifics you might offer are more than welcome.


    John Michael Hauck

    Friday, July 20, 2012 8:16 PM
  • @John - just saw your other blog posts (made a few comments).  Would love to know why not contribute to Callisto instead of roll your own if one was already out there? (feel free to take to email...my email is on my site)

    Tim Heuer | Program Manager, XAML | http://timheuer.com/blog | @timheuer

    (if my post has answered your question, please consider using the 'mark as answer' feature in the forums to help others)

    Friday, July 20, 2012 8:31 PM
  • @DLamb - while not in PDF form the areas are identified in PSD files downloadable from http://design.windows.com

    Tim Heuer | Program Manager, XAML | http://timheuer.com/blog | @timheuer

    (if my post has answered your question, please consider using the 'mark as answer' feature in the forums to help others)

    Friday, July 20, 2012 8:31 PM
  • Tim,

    I take your question as a great compliment.  Thanks.

    I'm certainly not adverse to contributing to Callisto. One small difference in our approaches might be a topic you touch on in your blog.  You mentioned that Callisto might feel more like a kitchen sink rather than a modular set of solutions. When I started w8isms.blogspot.com I thought it would be easier for me personally to contribute one small module at a time to the WinRT community. NuGet just reinforces that idea since it is such a great clearinghouse for a plethora of tiny modules - kind of like dim sum.

    In my day job, I manage and develop C#/WPF scientific apps.  We have not moved to Metro yet, so most of my Metro work is done after hours.

    I hope I answered your question.


    John Michael Hauck

    Saturday, July 21, 2012 2:43 PM
  • So, how would I go about writing nested settings for e.g. Account Management? (See Windows Mail App Preview for Example of what I mean.)

    Specifically how do I get the GoBack Button to only GoBack one step in the hierarchy rather than taking me back to the SettingsPane?

    Friday, August 3, 2012 9:55 AM
  • ARadsziwill,

    You ask, "So, how would I go about writing nested settings...".  This morning I updated CharmFlyout to support a new property called IsSubFlyout.  The demo code that shows this now also available.  Links to binaries and source are at the end of this post.

    So, in the definition of your sub-setting flyout, set IsSubFlyout=true like this:

    <UserControl
        x:Class="CharmDemoGridApp.MyCharmFlyouts"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        xmlns:local="using:CharmDemoGridApp"
        xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
        xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
        xmlns:cfo="using:CharmFlyoutLibrary"
        mc:Ignorable="d">
        <Grid>
            <cfo:CharmFlyout
                x:Name="cfoAbout"
                Heading="My About"
                HeadingBackgroundBrush="#FF4E0000">
                <StackPanel>
                    <TextBlock
                        FontSize="16">CharmFlyout by John Michael Hauck</TextBlock>
                    <TextBlock
                        FontSize="16">For support:</TextBlock>
                    <HyperlinkButton
                        Click="OnMailTo">support@bing.com</HyperlinkButton>
                </StackPanel>
            </cfo:CharmFlyout>
            <cfo:CharmFlyout
                x:Name="cfoSettings"
                Heading="My Settings"
                HeadingBackgroundBrush="#FF4E0000">
                <StackPanel>
                    <TextBlock
                        FontSize="16">Setting A</TextBlock>
                    <TextBlock
                        FontSize="16">Setting B</TextBlock>
                    <TextBlock
                        FontSize="16">Setting C</TextBlock>
                    <Button
                        Foreground="Black"
                        Click="Button_Click_1"
                        Content="View Sub-Settings" />
                </StackPanel>
            </cfo:CharmFlyout>
            <cfo:CharmFlyout
                x:Name="cfoSubSettings"
                Heading="My Sub-Settings"
                HeadingBackgroundBrush="#FF4E0000"
                IsSubFlyout="True">
                <StackPanel>
                    <TextBlock
                        FontSize="16">Sub-setting 1</TextBlock>
                    <TextBlock
                        FontSize="16">Sub-setting 2</TextBlock>
                </StackPanel>
            </cfo:CharmFlyout>
        </Grid>
    </UserControl>
    

    Then, in the code-behind, wire up the OnClick handler for the "View Sub Headings" button to open up the sub headings flyout:

            private void Button_Click_1(object sender, RoutedEventArgs e)
            {
                cfoSubSettings.IsOpen = true;
            }

    Behind the scenes: In the CharmFlyout custom control, I added the IsSubHeading dependency property and change the handler for the back button to look like this:

    BackCommand = new RelayCommand(p => { IsOpen = false; if (!IsSubFlyout) SettingsPane.Show(); });

    A pretty easy change - I really hope this helps!

    Links:

    CharmFlyout binaries reside here: http://nuget.org/packages/charmflyout/
    CharmFlyout source resides here: http://charmflyout.codeplex.com/
    Discussion: http://w8isms.blogspot.com/2012/07/charmflyout-another-charming.html



    John Michael Hauck

    Friday, August 3, 2012 12:22 PM
  • Well, what a nice coincidence!

    I will have a look at it first thing on monday morning. Thank you for sharing!

    Friday, August 3, 2012 3:11 PM
  • Hi ARadsziwill,

    When using regular Popup controls for flyouts that are declared in the XAML, nesting or layering secondary settings panes seems to be pretty trivial.
    In my project I did a quick test and was able to simulate the scenario you describe with a few very simple steps:

    I slapped a button (for the "Add and account" option) inside one of my existing secondary popups (call it puAccountsSecondarySettingsPane for sake of discussion).
    It triggers another popup by calling:

         puAnotherSecondarySettingsPane.IsOpen = true;

    in that button's click event. 
    Clicking that button then gets the popup where the Account adding functionality happens to appear over the first popup.

    The close button click event of puAnotherSecondarySettingsPane would have the typical

         puAnotherSecondarySettingsPane.IsOpen = false;

    along with a line to set a page level bool flag so that I can differentiate if this pane gets closed through this button or through a light dismiss:

         HardDissmissAnotherSecondarySettingsPane = true;

    I then added a Closed event for this pane so that it could also close the previous pane when a light dismiss occurs

    private void puAnotherSecondarySettingsPane_Closed(object sender, object e)
            {
                if (!HardDissmissAnotherSecondarySettingsPane)
                {
                    puAccountsSecondarySettingsPane.IsOpen = false;
                }
                HardDissmissAnotherSecondarySettingsPane = false;
            }

    At the page level I also declared the bool flag

         bool HardDissmissAnotherSecondarySettingsPane = false;

    That seems to do the trick and to provide good behavior for the different interaction scenarios that I tried out.
    Have you encountered any other problems or issues with implementing nested panes?
    I can't speak to the third party wrapper controls since I have not tried them out and have not found them to be necessary.

    Friday, August 3, 2012 7:45 PM
  • @JohnMichaelHauck8

    It took me a bit longer than expected, but now I had the chance to play around with your Library.

    Thank you again for sharing this. It really works like a charm (pun intended).

    Tuesday, August 7, 2012 2:33 PM