Desktop-as-a-Service Designed for Any Cloud ? Nutanix Frame
As we undertake examination of the CE Remote API, or RAPI, we have a couple of practical logistical considerations that weren't part of the picture when we operating in a standalone CE mode: Creating a CE-to-desktop connection, and accounting for performance delays that connection may incur.
If you are connecting to a CE device using a serial link (rather than Ethernet or network connection), the upcoming example programs may execute very slowly. Depending on what you are doing, the access time may be up to a couple of minutes. Walking the Registry tree or getting the files from a large directory are two examples of time-consuming operations. For this reason, I'd strongly recommend that you invest in an Ethernet link for your CE-to-Desktop connection, even if ultimately your application will connect serially.
Because of the large volume of code necessary to an MFC application, I have chosen to omit some of the project files from the source listings shown in this example. The omitted files fall into two categories: the files that contain the application's resources, and those which consist of "boiler plate" generated by the development environment. On balance, these wouldn't add to our explorations, and their sheer bulk might tend obscure the more important material.
Table 1: RapiDemo Project Source Files and Their Uses
|Source File Name||Header File Name||Implements||File Shown In Example|
|MainFrame.cpp||MainFrame.h||Default frame window||No|
|AllPages.cpp||AllPages.h||Property Sheet Object||Yes|
An Overview of the RapiDemo Example
Because there are such a multitude of files and objects that comprise an MFC application, I'd like to start with an overall strategic view of the project. In the RapiDemo example, here's a litany of what objects are being constructed, the chronology of their construction, and the relationship between the objects:
- The application object, RapiDemoApp, is constructed first. It, in turn, creates the document, view, and main frame window objects and establishes a relationship among them. The Visual C++ development tools generate this part of the application automatically.
- In addition, the RapiDemoApp object performs some application specific initialization. This happens in the CRapiDemoApp::InitInstance() function. We make modifications to this function to create and launch a property sheet control.
- Our application implements a property sheet control in the class CAllPages, which is derived from the standard MFC class CPropertySheet.
- An application-specific class, derived from the MFC base class CPropertyPage, implements each page in the property sheet control.
- CAllPages includes a member variable for each individual page of the property sheet. The type of the member variable is the class that implements the page it represents. There are three pages in the control and three member variables that represent them in CAllPages.
- The three RapiDemo property sheet page classes implement page specific initialization and input handling behavior.
- When the property sheet control is launched, the visible page receives user input. The class that implements the page handles the input.
- When the user changes pages by clicking on the property sheet tabs, the property sheet control transparently handles generic page changing behavior. The application has to do application specific initialization for the newly visible page.
- In this example, each page initializes the RAPI subsystem, makes RAPI calls, updates dialog controls on the page, and then unitializes RAPI.
Here's how the RapiDemo example looks when the application is launched. The default page, System Status, has been initialized with values queried from the CE device.
Figure 1: Rapi Demo Running on Desktop Windows.
In the next lesson, we'll look into the initialization processing for the RapiDemo application.