Form objects can be in one of five distinct states, depending on what methods have been called in them and whether any errors have occurred in performing those methods. The states are described in the following topics:
The states primarily relate to the status of the data in the form object. The different states reflect whether the data needs to be saved, whether the form object should allow modifications to the data, and what point in the process of saving the data the form is in. As such, the form states and transitions between them have more to do with your form server's implementation of IPersistMessage interface methods than any other. Knowledge of these states is very useful for proper implementation of the MAPI form interfaces that your form server must implement.
Each state is described in the following sections, along with the legal actions that cause transitions to other states. Any transitions not listed in the following sections are illegal. If your form objects make illegal transitions between states, they will not behave in the ways that messaging clients expect and could cause unpredictable client or form object behavior.
Note Some state transitions depend on information from previous states. Your form server will most likely have to implement a "dirty" flag in its form objects to indicate whether the values of the message's properties have been changed in order to facilitate later state changes.