📄 ch15.htm
字号:
<LI>Click the <U>C</U>lose button to close the Properties dialog.
</OL>
<P>If you need to see when a property value changes, select <U>V</U>iew, <U>N</U>otification
Log to open the Notification Log window. Whenever a property changes, a message will
appear in this window (see fig. 15.18). If the property you are changing supports
the <TT>OnRequestEdit</TT> notification, use the<TT> OnRequestEdit( )</TT> Response
radio buttons on the Notification Log dialog to see how your control reacts to the
different responses from <TT>OnRequestEdit</TT>. <B><BR>
<BR>
</B><A HREF="Art/15/15fig18.jpg"><B>FIG. 15.18</B></A> <I><BR>
Use the Test Container's Notification Log dialog to show the data-binding notifications
when a property value changes.</I></P>
<P>To invoke a method, follow these steps:
<OL>
<LI>Click the control you inserted in the main window of Test Container to select
the control.
<P>
<LI>Select <U>E</U>dit, In<U>v</U>oke Methods to open the Invoke Control Method dialog.
<P>
<LI>Select a method from the <U>N</U>ame combo box at the top of the Invoke Control
Method dialog (see fig. 15.19).
<P><A HREF="Art/15/15fig19.jpg"><B>FIG. 15.19</B></A> <BR>
<I>Select a method from the top section of the Invoke Control Method dialog, set
the para-meter values in the middle section, and view the method's return value in
the bottom section.</I></P>
<LI>Enter the needed values in the parameter text boxes shown in the center of the
Invoke Control Method dialog.
<P>
<LI>Click the Invoke button to invoke the method. If there is a return value from
the method, it will display at the bottom of the Invoke Control Method dialog.
<P>
<LI>When you finish invoking methods, click the Close button to close the dialog.
</OL>
<P>To fire an event, perform an action that will cause the event to fire. For example,
if you are testing the <TT>MFCControlWin</TT> control, you could invoke the <TT>CaptionMethod</TT>
method to fire the <TT>Change</TT> event. To view which events are firing, select
<U>V</U>iew, <U>E</U>vent Log to display the Event Log dialog. When an event fires,
the call to the event handler is displayed in the Event Log dialog (see fig. 15.20).
<B><BR>
<BR>
</B><A HREF="Art/15/15fig20.jpg"><B>FIG. 15.20</B></A> <I><BR>
When an event fires, the call to the event handler is displayed in the Event Log
dialog.</I></P>
<P>To select which events are displayed, open the Events dialog for the control by
selecting <U>E</U>dit, View <U>E</U>vent List. An example of the dialog is shown
in Figure 15.21. To toggle between showing and not showing an event, select the event
and click the <U>L</U>og/No Log button. To log all events, click the Log <U>A</U>ll
button. To not log any events, click the Log <U>N</U>one button. Click the <U>C</U>lose
button when you are finished. <B><BR>
<BR>
</B><A HREF="Art/15/15fig21.jpg"><B>FIG. 15.21</B></A> <BR>
<I>If you want to display the events for the <TT>MFCControl</TT>, this is how the
Events dialog will look.</I></P>
<P>The ActiveX Control Test Container provides a way for you to test the functions
in your control. Select <U>E</U>dit, Embedded Object <U>F</U>unctions to see a submenu
of the functions. Select a function to execute, and that function will be executed.
Table 15.1 lists the functions with a brief description. <BR>
<BR>
<TABLE BORDER="1" WIDTH="100%">
<CAPTION><B>Table 15.1</B><SPACER TYPE="HORIZONTAL" SIZE="10"><B> Embedded Object Functions</B></CAPTION>
<TR ALIGN="LEFT" rowspan="1">
<TD ALIGN="LEFT" VALIGN="TOP"><B>Action</B></TD>
<TD ALIGN="LEFT" VALIGN="TOP"><B>Description</B></TD>
</TR>
<TR ALIGN="LEFT" rowspan="1">
<TD ALIGN="LEFT" VALIGN="TOP">Primary Verb</TD>
<TD ALIGN="LEFT" VALIGN="TOP">Invokes control's primary verb.</TD>
</TR>
<TR ALIGN="LEFT" rowspan="1">
<TD ALIGN="LEFT" VALIGN="TOP">Activate</TD>
<TD ALIGN="LEFT" VALIGN="TOP">Activates control and puts it in Loaded state.</TD>
</TR>
<TR ALIGN="LEFT" rowspan="1">
<TD ALIGN="LEFT" VALIGN="TOP">UI Activate</TD>
<TD ALIGN="LEFT" VALIGN="TOP">Puts control in UI Active state.</TD>
</TR>
<TR ALIGN="LEFT" rowspan="1">
<TD ALIGN="LEFT" VALIGN="TOP">Close</TD>
<TD ALIGN="LEFT" VALIGN="TOP">Closes control and puts it in Loaded state.</TD>
</TR>
<TR ALIGN="LEFT" rowspan="1">
<TD ALIGN="LEFT" VALIGN="TOP">Deactivate</TD>
<TD ALIGN="LEFT" VALIGN="TOP">Deactivates control and puts it in the Loaded state.</TD>
</TR>
<TR ALIGN="LEFT" rowspan="1">
<TD ALIGN="LEFT" VALIGN="TOP">Deactivate UI Only</TD>
<TD ALIGN="LEFT" VALIGN="TOP">Restores OLE Control Test Container's original state.</TD>
</TR>
<TR ALIGN="LEFT" rowspan="1">
<TD ALIGN="LEFT" VALIGN="TOP">Hide</TD>
<TD ALIGN="LEFT" VALIGN="TOP">Hides control and puts it in Loaded state.</TD>
</TR>
<TR ALIGN="LEFT" rowspan="1">
<TD ALIGN="LEFT" VALIGN="TOP">Open</TD>
<TD ALIGN="LEFT" VALIGN="TOP">Puts control in stand-alone mode and Open state.</TD>
</TR>
<TR ALIGN="LEFT" rowspan="1">
<TD ALIGN="LEFT" VALIGN="TOP">Reactivate and Undo</TD>
<TD ALIGN="LEFT" VALIGN="TOP">Reactivates control and puts it in Loaded state.</TD>
</TR>
<TR ALIGN="LEFT" rowspan="1">
<TD ALIGN="LEFT" VALIGN="TOP">Run</TD>
<TD ALIGN="LEFT" VALIGN="TOP">Runs control and puts it in Loaded state.</TD>
</TR>
<TR ALIGN="LEFT" rowspan="1">
<TD ALIGN="LEFT" VALIGN="TOP">Show</TD>
<TD ALIGN="LEFT" VALIGN="TOP">Activates control and puts it in UI Active state.</TD>
</TR>
<TR ALIGN="LEFT" rowspan="1">
<TD ALIGN="LEFT" VALIGN="TOP">Properties</TD>
<TD ALIGN="LEFT" VALIGN="TOP">Shows property sheet for control.</TD>
</TR>
</TABLE>
<BR>
<BR>
The Test Container can run in two modes: Passive Container Mode or Simulated Design
Mode. When Test Container is in Passive Container Mode, it does not automatically
change the control's state. When it is in Simulated Design Mode, it does change the
control's state automatically to mimic Design mode.</P>
<P>A powerful feature of the Visual C++ Debugger is the fact that you can integrate
an executable. This means you can use OLE Control Test Container, or another container,
to test your control and be able to step through the code. You could use the Visual
Basic executable to test design mode and use a Visual Basic executable to test run
mode. To set this up, use the following steps:
<OL>
<LI>Select <U>P</U>roject, <U>S</U>ettings from the Developer Studio menu to open
the Project Settings dialog.
<P>
<LI>If you have not compiled and linked in Debug mode recently, you should compile
and link the debug version before continuing. The debug version must match the registered
version for the debugger to work correctly.
<P>
<LI>Make sure that Win32 Debug is selected in the <U>S</U>ettings For combo box.
<P>
<LI>Select the Debug tab (see fig. 15.22).
<P><A HREF="Art/15/15fig22.jpg"><B>FIG. 15.22</B></A> <BR>
<I>Make sure Win32 Debug is selected in the </I><CITE>S</CITE><I>ettings For list
box, and then select the Debug tab.</I></P>
<LI>Enter the name of the executable you want to use with the debugger in the <U>E</U>xecutable
for debug session text box. If you want to use the OLE Control Test Container, enter
<B>TSTCON32.EXE</B> with the proper path. It can be found in the BIN directory of
your Visual C++ directory. If you want to use the Visual Basic development environment,
enter <B>VB5.EXE</B> with the proper path. You will find VB5.EXE in your Visual Basic
directory.
<P>
<LI>Click the OK button to save the settings, and exit the Project Settings dialog.
<P>
<LI>Set any breakpoints you need to debug your control.
<P>
<LI>Select <U>B</U>uild, Start <U>D</U>ebug, <U>G</U>o, or press F5 to start the
debugger.
<P>
<LI>A Microsoft Developer Studio dialog will appear, alerting you that there is no
debug information for TSTCON32.EXE, or VB5.EXE if you're using Microsoft Visual Basic.
It also asks you to press the OK button to continue. Click the OK button; you don't
need to debug information for TSTCON.32EXE or VB5.EXE. If you want to prevent this
dialog from appearing again, click the Do not _prompt in the future check box.
<P>
<LI>Use the container as needed. The debugger will pause at the breakpoints after
switching from the container application to the debugger. You can step through code,
check values, and so on.
<P>
<LI>When finished, exit the control application, or select <U>D</U>ebug, Stop <U>D</U>ebugging
to exit the debugger.
</OL>
<H3><A NAME="Heading13"></A>Users</H3>
<P>One of the best testing tools is your user community. If you correctly analyze
the needs of your users before you even begin to create a control and use that knowledge
during development, you will have a more marketable and widely used control. You
also need to involve your user community in the testing of the control. Their feedback
is needed not only to report bugs, but also to let you know how they like the look
and feel. Feedback on the look and feel lets you know if you missed anything during
the needs analysis and if your control will be popular.</P>
<P>When choosing users to be beta testers, include users with many different needs.
For example, don't have all your beta testers use your control with only Visual C++.
Select some who will be using your control with Visual C++, Visual Basic, the Internet,
and so on. Make sure your group of beta testers will fully test the control's functionality.
If you are developing controls for internal use, make sure the end users you select
will use the system you are creating in a manner that fully tests your control.</P>
<P>Make sure that you stay in constant communication with your beta testers either
through personal contact or through support personnel. Keeping in touch will let
you know how they like the product. It will also let you know that the control is
being well tested and that you are resolving all bugs. Make sure you fully explain
the functionality of your control to the users. They can't test well if they don't
understand what they are testing.</P>
<P>When users report a bug, ask them to explain exactly what they did to get the
bug and what they did just before the bug occurred. This process may take a couple
of phone calls or e-mails. The bug could be caused by something they did earlier;
get as much information as possible. Next try to duplicate the problem. When duplicating
the problem, try to create their environment--exactly. For example, if they are using
Windows 95, try to duplicate the problem on Windows 95, not Windows NT. This applies
to hardware as well. If they are using a machine that is slow and doesn't have much
memory, don't try to re-create the problem on a souped-up development machine. We
know this is difficult to do, but the closer you are to their environment, the quicker
you will find the problem, and the better your chance of solving the real problem.</P>
<P>When you or your users find a bug, it is a good idea to try the control in different
types of test containers to see how it behaves. Because different containers use
ActiveX components in different ways, the problem may be in the way a container is
using the control. For example, Microsoft Visual Basic uses an ActiveX control differently
than the Visual C++ OLE Control Test Container. How a control behaves in different
types of containers may also give you a better idea of what the problem is. The Microsoft
OLE/COM Object Viewer tool (OLEView.exe) included with the Microsoft ActiveX SDK
is also a good tool for debugging. It allows you to view the interfaces and components
of an ActiveX control. Microsoft OLE/COM Object Viewer shows you what interfaces,
constants, properties, and methods are contained in the registered copy of the ActiveX
control. If the components of the control don't appear as you expect, maybe your
ActiveX object didn't register correctly. Use The Microsoft OLE/COM Object Viewer
to display the registry entries for the control.</P>
<P>The Microsoft OLE/COM Object Viewer is a good tool for checking the setup of your
ActiveX objects. A copy of the Microsoft OLE/COM Object Viewer is available in the
\Bin directory of the Microsoft ActiveX SDK directory or from Microsoft's Web page
on the OLE/COM Object Viewer tool (<A HREF="http://www.microsoft.com/oledev/olecom/oleview.htm"><B>http://www.microsoft.com/oledev/olecom/oleview.htm</B></A>).
Usually the Web site contains the most recent copy of the OLE/COM Object Viewer.
<H3><A NAME="Heading14"></A>Automated Tools</H3>
<P>Automated testing tools can also be used to test your control. These tools allow
you to build scripts that store keystrokes to create unattended, consistent automated
tests. The same script can be run across multiple machines, ensuring the same tests
are run on different platforms. This helps to eliminate problems occurring on one
platform and not another. If you add a new feature, you can add the needed tests
to the script once and copy the script across all test machines. You don't have to
manually retest on every platform, saving time and money.</P>
<P>One testing tool that supports testing ActiveX controls is the Rational Visual
Test. (Rational recently acquired this product from Microsoft.) Rational plans on
integrating Visual Test with its Rational Rose visual modeling tool. You can find
information on testing ActiveX controls in the Microsoft Knowledge Base and in the
Visual Test help files.
<H2><A NAME="Heading15"></A>From Here...</H2>
<P>This chapter has focused on using and testing your ActiveX component implementation.
While the majority of the discussions revolved around ActiveX Controls, it is important
to note that the same techniques can be applied to just about any component you develop.
In addition to the tools we pointed out, more are appearing every day that incorporate
ActiveX, including FrontPage and Visual InterDev and Microsoft BackOffice applications,
such as Microsoft Transaction server and Microsoft SQL Server.</P>
<P>When creating, using, and distributing your component, you need to be as thorough
as possible. Give the component to as many users as is feasible and test in as many
containers as is practical.
</p>
<p><hr></p>
<center>
<p><font size=-2>
© 1997, QUE Corporation, an imprint of Macmillan Publishing USA, a
Simon and Schuster Company.</font></p>
</center>
</BODY>
</HTML>
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -