Exploring RapiDemo Initializations
Initializing The System Status Property Page
In this case, we don't have to make any changes to the header file for the CSystemStatusPage class. All of our modifications are to the SystemStatusPage.cpp implementation file. by including the RAPI header.
#include <rapi.h>
The behavior of the System Status page is entirely implemented in the initialization member function, CSystemStatusPage::OnInitDialog().
BOOL CSystemStatusPage::OnInitDialog() { CPropertyPage::OnInitDialog(); SYSTEM_INFO SystemInfo; STORE_INFORMATION StoreInfo; SYSTEM_POWER_STATUS_EX PowerStats; MEMORYSTATUS MemStats; CEOSVERSIONINFO VersionInfo; char szInfoBuff[64];
The data declaration in OnInitDialog() consists almost entirely of structures that will be familiar from earlier examples. The code below illustrates the use of their members but not exhaustively. The key thing to keep in mind about these structures is that all of their string members will be reported to your program in Unicode format. To display them in the list control, all strings must first be translated back into a multibyte character set format.
//Initialize RAPI before use HRESULT hr = CeRapiInit(); if ( hr != ERROR_SUCCESS ) { return FALSE; }
Before we can use the RAPI subsystem, we must make it available to our application by calling the CeRapiInit() function. Always test the return from this call before continuing with RAPI operations. When you are finished making RAPI calls, you must uninitialize the subsystem and free its resources by calling the CERapiUninit() companion function.
//Uninitialize RAPI when you are finished making RAPI calls CERapiUninit().
You may wonder why we didn't just initialize RAPI in the constructor of the application object RapiDemoApp and uninitialize it in the destructor. In theory, this seems the sensible thing to do. However, in my experience, the RAPI connection tends to be more stable if initialization and uninitialization closely bracket your RAPI operations.
The first RAPI call we make is CeGetVersionEx(). RAPI function names and argument lists are generally the same as the CE side counterpart, except the function name is prefixed by "Ce". Notice we use sprintf() to format strings to insert in the m_SysStatsList listbox. The members of the CEOSVERSIONINFO structure being displayed are all of type DWORD. Being numeric, they need no translation and can be passed as arguments to single byte string handling routines.
CeGetVersionEx((LPCEOSVERSIONINFO) &VersionInfo); sprintf( szInfoBuff, "%s", "CE Version Stats:" ); m_SysStatsList.InsertString( -1, szInfoBuff ); sprintf( szInfoBuff, " %s : %li", "Major Version", VersionInfo.dwMajorVersion ); m_SysStatsList.InsertString( -1, szInfoBuff ); sprintf( szInfoBuff, " %s : %li", "Minor Version", VersionInfo.dwMinorVersion ); m_SysStatsList.InsertString( -1, szInfoBuff ); sprintf( szInfoBuff, " %s : %li", "Build Number", VersionInfo.dwBuildNumber); m_SysStatsList.InsertString( -1, szInfoBuff ); sprintf( szInfoBuff, " %s : %li", "Platform Id", VersionInfo.dwPlatformId); m_SysStatsList.InsertString( -1, szInfoBuff ); m_SysStatsList.InsertString( -1, " " );
Next, we use CeGlobalMemoryStatus() to retrieve memory statistics. Once again, we can use the MEMORYSTATUS structure's numeric members without translation.
CeGlobalMemoryStatus((LPMEMORYSTATUS) &MemStats); sprintf( szInfoBuff, "%s", "CE Memory Stats:" ); m_SysStatsList.InsertString( -1, szInfoBuff ); sprintf( szInfoBuff, " %s : %li", "PerCent Usage", MemStats.dwMemoryLoad); m_SysStatsList.InsertString( -1, szInfoBuff ); sprintf( szInfoBuff, " %s : %li", "Total Physical Memory", MemStats.dwTotalPhys); m_SysStatsList.InsertString( -1, szInfoBuff );
Page 2 of 3
This article was originally published on June 24, 2004