Build a Flyout Search Control
Give users a versatile way to search for records without consuming screen real estate.
by Kathleen Dollard
November 2003 Issue
Technology Toolbox: VB.NET
Users of business applications often need to search for specific records. They might want multiple sets of search criteria but still wish to minimize the screen real estate the search window consumes. This article shows you how to build a search control that expands, or flies out, when it's in use, then collapses to minimize its real estate when not in use. Radio buttons let the user choose from multiple sets of search criteria. Each set uses a unique combination of entry controls. The user's interaction is intuitive because the search control stays visible to let the user switch at will between searching and data entry (see Figure 1).
Creating the search flyout control combines important .NET techniques, including inheritance, strongly typed collections, working with dynamic controls, and raising custom events. It combines these fundamentals and hides interface gymnastics in a single, easy-to-use control. When you use the control in your application, you only need to set values in a few properties dialogs and handle events that fire when the user initiates or cancels a search.
Although the control is easy to use, it's complex internally, consisting of five classes. The main control—SearchRadioPanel—derives from Windows.Forms.Panel. This panel contains a collection of derived radio buttons named SearchRadioButton. Each derived radio button includes a collection of Criteria that define the caption, type, and field name for the controls to display. SearchRadioButtonCollection, SearchRadioButton, CriteriaCollection, and Criteria are all nested classes within SearchRadioPanel. Inheritance lets you leverage the Panel and RadioButton to do most of the work. The SearchRadioPanel combines their behavior in a unique way and extends these classes to provide the search flyout behavior.
Both the SearchRadioButtonCollection and the CriteriaCollection are strongly typed. This means the compiler forces entries in the collection to be of the specified type. Each collection derives from CollectionBase. However, don't copy and paste from the example under the CollectionBase topic in the .NET help, because it's seriously flawed, at least in how it evaluates correct types, and it doesn't call base methods for overridden events.
SearchRadioPanel relies on the strongly typed collection's design-time behavior. Using a strongly typed collection gives you collection properties pages at design time automatically. The values you enter in the properties pages aren't persisted unless the class, or one of its base classes, includes the Serializable attribute. Windows.Forms.Control includes this attribute, so you need to include it explicitly only for the Criteria class that derives from System.Object. The properties page for the RadioButtonPanel contains all the properties for a Windows.Forms.Panel, as well as the SearchRadioPanel's extra properties. One of these new properties is the SearchRadioButtonCollection. Clicking on the ellipses next to SearchRadioButtonCollection opens a properties dialog that lets you manage the collection and edit each SearchRadioButton. Each SearchRadioButtion includes the properties of a Windows.Forms.RadioButton and some extra properties, including the SearchCriteriaCollection. Clicking on the SearchCriteriaCollection's ellipses opens a second properties dialog that lets you manage the criteria.
Initialize the Control
.NET provides all the design-time behavior I've described, so you can turn to the runtime issues (see Listing 1 for key portions of the control's code). The code in Listing 1 modifies the constructor to call InitializeControl. InitializeControl initializes controls that the SearchRadioPanel always includes. Windows.Forms often generates this code, but in this case you give up some code-generation and design-time aids by inheriting directly from a Windows.Forms.Control (RadioButton). You could derive from Windows.Forms.UserControl to provide this support, but deriving directly saves a little overhead and keeps the design simple. The pnlSearch object is the container for the dynamic criteria controls, the Go button initiates the search, and pnlBack has an alternate background color to provide a visual border for the search panel. SuspendLayout and ResumeLayout keep the Layout event from firing prematurely while the form loads.
It's important to differentiate the source of different controls. The three child controls you add to SearchRadioPanel in the InitializeControl method belong to the SearchRadioPanel and are only visible within it. SearchRadioPanel also acts as a container for SearchRadioButtons that belong to the calling form. If you look in the generated code region for the FlyOutTest form, you'll find five instantiated and initialized SearchRadioButtons. CriteriaCollection's default serialization puts the Criteria values into the form's resource file. The pnlSearch contains a third category of control, which includes the labels and textboxes that appear within the search panel. The pnlSearch instantiates these controls and destroys them before instantiating a new set of entry controls.
Back to top
|