Cancel SettingsFlyout Hide when there is a Validation Error RRS feed

  • Question

  • I need to cancel a SettingsFlyout hide when there is a validation error and I cannot figure out how to do it.

    I have a SettingsFlyout which contains a simple HTML form for entering a user name and password:

    <!DOCTYPE html>
            <script type="text/javascript" src="securitySettings.js"></script>
            <div id="divSecurity" 
                <div class="win-header" 
                    <div class="win-label">Security</div>
                <div class="win-content">
                <form id="frmSecurity">
                            User Name:
                            <input required />
                            <input type="password" required />

    Notice that both the userName and password fields are required (using the HTML5 required attribute).

    I want to validate the form before saving the userName and password. So, I am using the following code:

    (function () {
        'use strict';
            ready:function(element,options) {
                var divSecurity = document.getElementById("divSecurity").winControl;
                var frmSecurity = document.getElementById("frmSecurity");
                divSecurity.addEventListener("beforehide", function (evt) {
                    var good = frmSecurity.checkValidity();
                    // Nothing below works!

    Here's the problem:  I want to prevent the SettingsFlyout from hiding when there is a validation error. I am trying to prevent the SettingsFlyout from hiding within the beforehide event but I cannot figure out how to do it. I've tried:  evt.preventDefault(), evt.stopPropagation(), evt.stopImmediatePropagation(), and even calling show() again on the original SettingsFlyout control. None of these approaches work.

    Therefore, the question is how do you include a form (with validation) in your app settings?  I've read the guidance here http://msdn.microsoft.com/en-us/library/windows/apps/hh770544.aspx and it states:

    When a user changes a setting, the app should reflect the change immediately. A new setting value is applied as soon as the user stops interacting with a particular setting control. This is recommended for light-dismiss surfaces. If your app doesn’t apply the new values to the settings store by the time the settings Flyout closes, the new values might be lost, because a settings Flyout shouldn't have a commit button. Handle the beforeshow and afterhide events to do control initialization and state serialization.

    So, it sounds like a separate submit button for the userName and password form would not be recommended. Suggestions?

      -- Stephen

    • Edited by S Walther Sunday, July 22, 2012 3:41 AM
    Sunday, July 22, 2012 3:41 AM


All replies

  • I don’t think it is a common practice to put username/password in the settings charm. Take the Mail app as an example, it allows you to add accounts in the settings charm. But it doesn’t allow you to type username/password. When you first connect to an email service, a dialog (not settings charm) is popped out to prompt for username/password. The credential is remembered by the app, so the user no longer needs to type it again. If the user changes the password on the internet, the dialog will pop up again asking for latest credential. You can take the same approach.
    Monday, July 23, 2012 5:14 PM
  • Hi Name-Dis,

    The username/password form is just an example -- my question is how do you handle validation in the Settings charm if you cannot prevent the SettingsFlyout from hiding its content. The guidelines say to handle saving settings data in the beforehide event -- but there is no way to cancel the hide in the beforehide event when there is a validation error.  The only solution that I know is to add a button to the form which is displayed by the SettingsFlyout.

       -- Stephen

    Tuesday, July 24, 2012 5:36 AM
  • Hi Stephen,  You cannot prevent the close.  You could reshow it:


    "defaults", "/html/MySettings.html");


    Jeff Sanders (MSFT)

    Tuesday, July 24, 2012 1:02 PM