Communication objects can provide several powerful capabilities:

• You can write PM code that handles and responds to help-related messages. For this, you would use a :docprof.-loaded "global" communication object.

• You can write PM code to override the default appearance of the IPF help interface. For example, you can provide custom push buttons in the control area. For this, you would use a :docprof.-loaded "global" communication object.

• You can write PM code that allows help information to include function simulation, user interaction, and audio and video presentations (see Controlling Windows with Applications (ACVIEWPORTS)). For this, you would use an :acviewport.-loaded communication object.

• You can write PM code that changes help information (including .INF files) dynamically, with help window contents generated and formatted at the time when the information is displayed to the user. For this, you would use a :docprof.-loaded or "global" communication object. For more information about changing help information dynamically, see Changing Help Information at Run Time (DDF).

Essentially, a communication object is intended to provide message processing when no application is present to handle this message processing. In other words, your stand-alone PM applications can provide the same functionality that is supported by communication objects.

However, unlike a stand-alone application, a communication object that properly handles message passing can be used by any stand-alone application and can interact with other communication objects. For example, a communication object that provides system call support (such as querying specific details about the user's system) might be useful to a broad range of applications in their online information.