Let’s start with the most important news:
From now on, I won’t link *.zip packages with the sources anymore, because NuGet really make life easier. If you want access to the source files, just drop me an email
There’s been one more or less important change to the Flyout control you should know about: It now has a property called “IsIgnoreLightDismissal”. To understand its purpose, imagine the following scenario (video below)
You have a Button control that opens a FilePicker/FolderPicker, asking the user to select a File/Folder. This Button is hosted inside a Flyout control.
Now when the user taps the Button, the Picker will popup, stealing the focus from your applications Window. Flyouts are required to hide on App-switch by the design guidelines, which is perfectly fine in most cases. BUT: The user does expect the Flyout to be open when he returns from the Picker, which is obviously not the case, as the Flyout hid, just like the guidelines require.
How do we solve this problem?
Well due to the IsIgnoreLightDismissal property you can do this quite easily: Before showing the Picker, set IsIgnoreLightDismissal = true. After the picker returned set the property back to false.
The Window-change, caused by the Picker results in the Flyout being ‘Light-Dismissed’. (LightDismiss is the same as tapping beside the Flyout.) In the events handling WindowActivation and Closing of the Flyout, a regular Window-change and a Picker-caused Window-change look the same, that’s the reason why you have to set IsIgnoreLightDismissal back to false when the Picker returns.
One more problem
I don’t know how many of you (though I’d like to know!) use my SettingsContractWrapper to integrate your with the settings contract, but I found myself in the highly unlikely scenario of having a FolderPicker, that had to be invoked by a control in the settings panel. The Flyout would hide just like explained above, but the problem is even more tricky: The instance of the Flyout, hosting my custom SettingsPanel control is created when the user selects the corresponding entry in the settings charm. Now the Button_Click event in the SettingsPanel, that opens the Picker was required to set the parental Flyout’s IsIgnoreLightDismissal property, remember? Q: How do we notify the content control of the Flyout (in this case a SettingsPanel) about its parental Flyout control? A: The SettingsEntry contructor has an optional callback, that is invoked by the SettingsContractWrapper the moment the Flyout is created, providing the Flyout as a parameter. The SettingsPanel on the other hand has a “public void ProvideParentalFlyout(Flyout parentalFlyout)” that got set as the callback in the SettingsEntry constructor.
Finally the SettingsPanel will know about the Flyout is is hosted in, so before the Picker is shown the Button_Click event has access to the Flyout.IsIgnoreLightDismissal property.
The FlyoutAndSettingsSample demonstrates the difference:
TCD.Controls on NuGet
FlyoutAndSettingsSample, demonstrating simple, as well as advanced scenarios
I’d like to hear what you think – especially if you find a bug!