Reusable Silverlight Popup Logic






3.73/5 (5 votes)
Encapsulated Popup logic for easy reusable Silverlight popups
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 theFrameworkElement
that will trigger thepopup
to close if the mouse leaves its screen area. Thepopup
will only remain open after leaving the owner if thepopupChild
element is supplied in this constructor and the mouse immediately enters the screen area of thepopupChild
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 theFrameworkElement
that triggers thepopup
panel to open. Thepopup
will open on theMouseLeftButtonUp
mouse event of the trigger.popup
- Thepopup
is thePopup
primitive control that contains the content to be displayed.popupChild
- ThepopupChild
is the child control of thepopup
panel. ThePopup
control does not raiseMouseEnter
andMouseLeave
events so the child control must be used to detect if thepopup
should remain open or closed in conjunction with the owner element. This value may be leftnull
to create situations where only the owner element controls whether thepopup
closes or not. e.g. an image could trigger apopup
that describes the image and thepopup
closes when the mouse leaves the image regardless of whether the mouse enters the description.placement
- Determines which side of the owner element thepopup
will appear on. This is anenum
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