|
|
Custom View OCX’s
This
sample contains a description of the custom view OCX’s for WMI and the
corresponding automation interface.
Custom views provide non-generic views of objects contained in the WMI database. The WMI CIM Studio Object Browser, and other
programs may use these custom views to display application specific views of
WMI objects. For example, a custom view
of a disk drive might show the amount of free space in a bar chart, and so on.
This sample is a
dialog-based application created by AppWizard and uses the Microsoft Foundation
Classes (MFC) for simplicity. The code is designed to be easy to follow and
doesn't necessarily show a good practice for building 'real' WMI client apps.
Concentrate on the steps and architect your application in a way that makes
sense for you.
Getting
Started with the Custom View OCX’s
Any number of views can be defined for each class stored in the
WMI database. To add a custom view to
the WMI database, it is necessary to create a new instance of the ClassView
class. Below is an example of a MOF
file that can be compiled to define a custom view for the Win32LogicalDisk
class. In this MOF file, the id
property takes the form of ClassName.ViewName, so that custom views can
be uniquely identified and easily recognized.
The WMI CIM Studio and Object Browser applications determine what
custom views are available for a given class by querying for all instances of ClassView
such that the ClassName property is equal to the current class being
displayed.
#pragma
namespace("\\\\.\\root\\cimv2")
class
ClassView
{
[key]
string id;
string
title;
string
ClassName;
string
classid;
string
codebase;
string
version;
};
instance
of ClassView
{
id
= "Win32_LogicalDisk.View1";
title
= "Custom View of Win32_LogicalDisk";
ClassName
= "Win32_LogicalDisk";
classid
= "{D5FF1886-0191-11D2-853D-00C04FD7BB08}";
codebase
= "";
version
= "1.0";
};
Building the Win32LogicalDisk Sample
The application can be
built from the command line using NMAKE, or it can be built using Microsoft
Visual C++.
From the command line
in the sample installation directory:
NMAKE /f "Makefile"
From Microsoft Visual
C++:
1.
Select File + Open Workspace
2.
Select the Win32LogicalDisk.dsp file
Using the Win32LogicalDisk Sample
To see a sample custom view in the WMI CIM Studio follow these
steps:
1.
Build the Win32LogicalDisk sample found in the WMI SDK directory under
samples\vc\customviews as described above.
2.
Use regsvr32 to register the resulting Win32LogicalDisk.ocx at the command line in the sample installation
directory:
regsvr32
Win32LogicalDisk.ocx
3.
Start the WMI CIM Studio application.
4.
Use the MOF Compiler Wizard in WMI CIM Studio to compile the
"CustomView.mof" MOF file that is included with the sample.
5.
In WMI CIM Studio, select the Win32_LogicalDisk class in the class
tree.
6.
In the Object Viewer (right pane), click the "Instances"
button to display all instances of "Win32_LogicalDisk" on your local
machine.
7.
Double-click one of the instances to go to the single object view
for that instance. At this point, the custom view available for instances of
this class is recognized and the "Views" menu-option under the
"Views" button becomes enabled.
8. Click the
"Views" button and select "Views..." in the menu. A dialog is displayed with a list of the
available views for this object. One of
them is the "Custom View of Win32_LogicalDisk" which is implemented
by our sample ocx. Selecting this option and clicking "OK" displays
the custom view showing (in this example) the total vs free disk space on the
current disk object.
General Notes
Things
to remember when you're building your own WMI client application:
1.
If you want your client to
run on NT and non-DCOM versions of Windows 95, manually load the ole32.dll and
see if CoInitializeSecurity() exists. This routine won’t exist on Windows 95
installations that don’t have DCOM installed separately. If this routine doesn't
exist, the asynchronous routines in this sample won’t work because of
mismatched security level problems. The synchronous techniques will still work.
2.
If you don’t care about
non-DCOM versions of Windows 95, you can define _WIN32_DCOM so that CoInitializeSecurity() is available for
implicit linking. Don't use _WIN32_WINNT to get this prototype since it won't
compile under the Windows 95/98 operating systems.
3.
In any case, the
CoInitializeSecurity() call (in InitInstance()) is required to work around a
security problem when WMI trying to call a Sink object but won't identify
itself. The CoInitializeSecurity() call turns off the authentication
requirement.
4.
WMI interfaces are defined
in wbemcli.h and wbemprov.h found in the wmi\include directory. You may #include both these files by
including just wbemidl.h located in the same directory.
5.
WMI interface CLSIDs are
defined in wbemuuid.lib. If you get unresolved externals in interfaces and
CLSIDs, this is what is missing.
6.
You'll need to link with
oleaut32.lib and ole32.lib to get the needed COM support.
7.
In the Link|Output
settings, specify 'wWinMainCRTStartup' as the entry point. This is per the
Unicode programming instructions.
8.
If you're using the makefiles, don't forget to set the Visual C++
environment variables. This is done by running VCVARS32.BAT.