Visual Basic Concepts
As mentioned in "Showing Forms from the CoffeeManager Class," modal and modeless forms displayed by an out-of-process component have a different relationship to a client application’s forms than they would if displayed by an in-process component. Running CoffeeWatch will demonstrate this.
Note This topic is part of a series that walks you through creating a sample ActiveX EXE. It begins with the topic Creating an ActiveX EXE Component.
To demonstrate modal and modeless form behavior with the out-of-process Coffee component
Depending on your system configuration, the order programs were started, and so on, the modal form may come up in front of CoffeeWatch — or you may see something like this:
The dialog box appears because CoffeeWatch is waiting on its call to CoffeeMonitor.ShowForm
, which is waiting on the modal TestForm. However, if TestForm were truly modal with respect to Form1, clicking on Form1 would generate a system sound indicating that Form1 was disabled.
Note Depending on your system configuration and the order in which programs are loaded, the copy of Visual Basic in which Coffee is running may come to the front along with TestForm, obscuring CoffeeWatch.
Note If you can’t see CoffeeWatch (the form, not the project), use the task bar (or press ALT+TAB) to bring it to the front.
In the strict sense of the word, TestForm is modal to CoffeeWatch. That is, you can’t do anything with CoffeeWatch until TestForm is dismissed. However, because the two forms are in different processes, CoffeeWatch can appear on top of TestForm.
TestForm behaves like a modeless form that’s not owned by CoffeeWatch. That is, it doesn’t stay on top of CoffeeWatch. You can verify this by clicking on each of the two forms, to bring them alternately to the front.
Important Because TestForm is in a different process from CoffeeWatch, you cannot make CoffeeWatch the owner of TestForm as you would if the forms were in the same process — that is, by passing a reference to CoffeeWatch in the OwnerForm argument of TestForm. For details see "Displaying Forms from Code Components," in "Building Code Components."
TestForm doesn’t close. (It may be hidden behind the instance of Visual Basic containing the CoffeeWatch project — use the task bar or ALT+TAB to bring it to the front.)
This illustrates two important points: First, a form displayed by an out-of-process component is not dependent on the client application. Nor is its lifetime limited by the client’s lifetime.
Second, a loaded form can keep an out-of-process component’s executable from unloading. For details, see "Starting and Ending a Component" in "General Principles of Component Design."
In its Terminate event, CoffeeMonitor should unload any forms it has shown.
Once you put an ActiveX EXE project in run mode, it remains in run mode. This is convenient for testing, but it’s different from the behavior of the made .exe. The executable for an out-of-process component unloads when the last client releases its last reference to an object provided by the component, as discussed in "Starting and Ending a Component."
Note The only way to test the shutdown behavior of an out-of-process component is to test with the made executable.
The lesson to take away from all this is that out-of-process code components are generally not the best way to show forms.
This topic is part of a series that walks you through creating a sample ActiveX EXE.
To | See |
Go to the next step | Providing an Asynchronous Notification Event |
Start from the beginning | Creating an ActiveX EXE Component |