Forms: Key Concepts
Updated: May 13, 2016
Applies To: System Center 2012 SP1 - Service Manager, System Center 2012 R2 Service Manager, System Center 2012 - Service Manager
Before customizing forms, you should be familiar with the following form concepts.
How Forms Are Used
When the management pack that contains the form definitions is imported into System Center 2012 – Service Manager, the form definitions are stored in the database. Later, when the user initiates a Service Manager console task that requires the display of an object, Service Manager must find a form to display the requested object. Service Manager accesses the database and searches for a form that has been defined for that object. If no form is defined for the object, Service Manager searches for a form that is defined for the object’s parent object. Service Manager continues to search the entire object’s inheritance hierarchy until it finds a defined form.
Generic Forms
If Service Manager cannot find any form for the object or for any of its parent objects, Service Manager dynamically builds a default generic form for that object. The generic form is a system-generated form that is sufficient for simple form use. The generic form represents a quick and easy way to create a form for objects without any form definitions.
By default, the generic form displays all the properties of the form in a simple layout that you cannot change. The generic form displays the properties of all the parent objects in the inheritance hierarchy of the form, and you cannot change that behavior. Customizations to the generic form are limited. For example, you can specify the properties that you want the generic form to display; however, the generic form cannot be used as a basis for customization. If you later define a custom form for that object, your custom form overwrites the object’s generic form.
For information about hiding properties in a generic form and other ways that you can customize a generic form, see the blog post Overview of the Forms Infrastructure and the Generic Form.
Combination Classes in Forms
Sometimes, you need a form to display information that is derived from more than one class. To do this, you create a combination class and then bind a field on the form to the combination class. For more information about combination classes, see Changes to the System Center Common Schema.
Functional Aspects of a Form
A form has the following functional aspects:
Initialization
Size and location
Refresh
Submit changes
These aspects are described in the following sections.
Initialization
During initialization, a form’s Extensible Application Markup Language (XAML) is parsed and all controls on the form are instantiated and loaded. The form’s Loaded event indicates when the form and all contained elements have been loaded. Data-loading operations are asynchronous. Therefore, the target instance may not be available when the Loaded event is raised. Instead, the DataContextChanged event must be used for notification when the target instance is set for the form. The PropertyChanged event for the DataContext property can be used in place of the DataContextChanged event.
We recommend that you use the Loaded event for control-related custom initialization and then use the DataContextChanged or PropertyChanged events on the DataContext property for target instance-related custom initialization.
Size and Location
When a form is displayed in a pop-up window, its initial size is determined based on the form’s Width, Height, MinWidth, and MinHeight properties. If these properties are not set for the form, the form’s initial size is calculated based on its content.
We recommend that you set these properties as follows:
Set the Width and Height properties of the form to explicitly specify the ideal size. Consider setting these properties to the Auto value. This sets the width and height of the form based on the size of the content.
Set the MinWidth and MinHeight properties of the form to specify the smallest window acceptable for the form. If a user resizes the window to a smaller size than specified, scrollbars appear for scrolling to the hidden form content.
When the form is hosted inside the Service Manager forms host, the last-used size and location is preserved for subsequent display of that form by the same user within the same run session.
Refresh
The target instance of a form can change as a result of executing a Refresh command on the form. The handler for this command fetches new data from the database. When the data arrives, the form’s DataContext property value is set to the new target instance and the DataContextChanged event is raised.
To differentiate between the DataContextChanged event that was raised when the form was first loaded and the event that was raised to handle a Refresh command, check the OldValue property of the event arguments that are passed in with the event. This property is null if the form has just been initialized.
Submit Changes
The form host pop-up window in Service Manager provides buttons for submitting changes that are made in the form and for closing the pop-up window.
When a user clicks the Apply button for a form, the form’s target instance is submitted for storage. This operation is synchronous; therefore, the user cannot edit the form until the submission operation is complete. If failure occurs during the form submission, an error message appears. The form remains open for further changes. We recommend that users apply their changes frequently to avoid collisions if another instance of the form is being edited at the same time.
If the user clicks the OK button, the behavior is similar to Apply, except that, if the form submission operation is successful, the form and its host window are closed.
If the user clicks the Cancel button, a dialog box appears that asks the user to confirm the operation. The user can click Yes and lose changes, or click No and return to the form.
See Also