Messaging Forms
You can change the behavior of the Messaging application (or any other messaging client application) by creating customized messaging forms. They are customized read and compose forms and can be used with new and existing transports. The behavior that they provide can vary, from adding new transport types such as Multimedia Messaging Service (MMS) to adding a new message type, such as one that supports playing a game like ticktacktoe.
A custom messaging form is a DLL that contains the customized read and compose forms, exports the FormFactoryEx function, and supports the IFormProviderEx and IMessageFormEx interfaces.
To become active, the form must be registered twice. The first entry registers the form as a message class, under the following registry key: HKEY_CURRENT_USER\Software\Microsoft\Inbox\MsgTypes\MessageClass. The second entry specifies the message transport(s) to use, under the following registry key: HKEY_LOCAL_MACHINE\Software\Microsoft\Inbox\Svc\TransportType\MsgClasses.
Note To respond to changes in the registry, the Messaging application must be restarted after the registry has been updated.
When the Messaging application displays or creates a message, it searches the registry for a DLL that matches the message class of the message. When the Messaging application finds a suitable DLL, it loads it and calls the FormFactoryEx function with the message class. The DLL responds by returning the IFormProviderEx interface.
The Messaging application (the host) uses the IMessageFormEx interface to communicate with the custom messaging form, which in turn uses the IMessageFormHostEx interface to communicate back to the Messaging application.
When processing messages with a custom messaging form, the Messaging application uses the mechanisms described in the following table.
| Action | Mechanism |
|---|---|
| Form creation | Custom read and compose forms are created whenever the Messaging application calls either IFormProviderEx::CreateComposeForm or IFormProviderEx::CreateReadForm. This causes the form to create its own window as a child of the form frame. Both the handle of the child window (the phwndBody parameter) and the IMessageFormEx interface pointer are returned.
The Messaging application uses the phwndBody parameter to pass on window messages that it does not process for the custom messaging form, and it uses the IMessageFormEx interface to communicate with the custom messaging form. When the Messaging application calls the CreateComposeForm and CreateReadForm methods, it passes in a pointer to its IMessageFormHostEx interface, which allows the form to communicate back to the Messaging application. |
| Displaying form menus | When the form is initially created, the Messaging application calls IMessageFormEx::GetMenuCapabilities to provide a way for the form to specify which optional menu commands it can process and to allow enabling or disabling of the menu items.
The commands that the form cannot process are disabled (appear grayed) on the form menu. GetMenuCapabilities is subsequently called each time a menu is about to appear. This allows enabling and disabling of menu commands dynamically. |
| Running the form | For message items that the form processes, the Messaging application calls IMessageFormEx::DoAction when the menu command is selected.
When the form communicates with the Messaging application, it uses the IMessageFormHostEx interface (which the Messaging application makes available to it when it creates the custom read or compose form). |
| Closing the form | The form can close itself at any point, which can be triggered by the following events: sending the message, deleting the message, clicking close on the message form, and clicking OK on the message form.
When the Messaging application calls IMessageFormEx::CloseForm, the form first calls IMessageFormHostEx::DoAction to have the Messaging application either close or delete the message, then the form calls IMessageFormHostEx::FormClosing. After calling FormClosing, the form posts a WM_CLOSE message to the parent window (which it received from the Messaging application on creation). This cleans up the handle to the window that is no longer in use. |
For more information, see How to: Register Customized Messaging Forms.
See Also
Messaging | Messaging Transports | Customized Messaging Rules Clients | Message Stores | How to: Register Customized Messaging Forms | Messaging Sample Code
Send Feedback on this topic to the authors