Forms: Key Concepts
应用到: System Center Service Manager 2010
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 to Service Manager, the form definitions are stored in the database. Later, when the user initiates a Service Manager 控制台 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 usages. The generic form is a quick and easy method to have 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. 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(https://go.microsoft.com/fwlink/?LinkId=208536).
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. 有关详细信息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
Each of these aspects is described below.
Initialization
During initialization, the form 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. It is important to realize that data loading operations are asynchronous so it would be wrong to presume that the target instance is available when the Loaded event is raised. Instead, the DataContextChanged event must be used to get notified 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.
It is recommended 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 the 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.
It is recommended 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 are displayed 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 the 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 one 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 the user clicks the Apply button for the form, the form’s target instance is submitted for storage. This operation is synchronous, so the user cannot edit the form until the submission operation has been completed. If failure occurs during the form submission, an error message is displayed. The form remains open for further changes. It is recommended 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.