Introduction
This code allows you to hookup a popup control to any trigger within a Silverlight application. It prevents the developer from having to rewrite the same event handlers and timers that such controls need. It also gives a brief example of just how exactly to use the Popup
primitive, but only so much as to get the purpose of the code across. I have called the code a PopupProvider.
Background
When I started working with the Popup
primitive control for Silverlight, I realized I was going to be rewriting the same logic over and over to open and close the control. For all the usual reasons one decides to refactor and encapsulate logic (reduce source size, maintain single copy, etc.), I wrote this piece of code.
Using the Code
The code is very quick and easy to use. First create a simple Silverlight user control that contains a Popup
primitive and a child control.
<UserControl x:Class="Example.Controls"
xmlns="http://schemas.microsoft.com/client/2007"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">
<StackPanel x:Name="LayoutRoot" Orientation="Horizontal">
<HyperlinkButton x:Name="TriggerButton" Content="Trigger"/>
<Popup x:Name="PopupControl">
<TextBlock x:Name="ChildText" Text="Popup Text"/>
</Popup>
</StackPanel>
</UserControl>
Next, add a private
field to the code behind to keep a handle on the PopupProvider
. And finally, intantiate the PopupProvider
in the constuctor of your user control. The final code will look something like this:
public ExampleControl()
{
InitializeComponent();
_popupProvider = new PopupProvider
(TriggerButton, TriggerButton, PopupControl, ChildText, Direction.Bottom);
}
private PopupProvider _popupProvider;
Notes on the constructor parameters (these are also available in the source file). The parameters below appear in the order in which they are used in the constructor.
owner
- The owner is the FrameworkElement
that will trigger the popup
to close if the mouse leaves its screen area. The popup
will only remain open after leaving the owner if the popupChild
element is supplied in this constructor and the mouse immediately enters the screen area of the popupChild
element after leaving the owner. The owner does not need to be the same control as the trigger, but it should contain the trigger. This is useful in situations such as when a search button should open some help text, but the help text should stay visible while the mouse is over the search text box as well. The owner in this case could be a panel that contains both the button and the text box.
trigger
- The trigger is the FrameworkElement
that triggers the popup
panel to open. The popup
will open on the MouseLeftButtonUp
mouse event of the trigger.
popup
- The popup
is the Popup
primitive control that contains the content to be displayed.
popupChild
- The popupChild
is the child control of the popup
panel. The Popup
control does not raise MouseEnter
and MouseLeave
events so the child control must be used to detect if the popup
should remain open or closed in conjunction with the owner element. This value may be left null
to create situations where only the owner element controls whether the popup
closes or not. e.g. an image could trigger a popup
that describes the image and the popup
closes when the mouse leaves the image regardless of whether the mouse enters the description.
placement
- Determines which side of the owner element the popup
will appear on. This is an enum
that is also included in the source code.
Points of Interest
The provider code itself is mostly just attaching events and handling state that is not too interesting. Probably the most valuable logic that I can share from within it is how the popup
control is positioned.
FrameworkElement page = Application.Current.RootVisual as FrameworkElement;
GeneralTransform gt = _owner.TransformToVisual(page);
Point p;
p = gt.Transform(new Point(0, _owner.ActualHeight - 2));
_popup.VerticalOffset = p.Y;
_popup.HorizontalOffset = p.X;
_popup.IsOpen = true;
There is obviously some room for error handling in there, but you get the point.
Also, I have some words of warning. I haven't used this control in a terribly wide variety of situations yet. I know there are several bugs to be fixed, other events that could be handled and many usability tweaks to be made. If you have any suggestions, let me know or feel free to implement them yourself.
History
- 2008-05-23: Made a couple of spelling fixes and added some description about the provider code