Visual C++ README.WRI Part 7-Foundation Class Library (1 of 2)

The information in this article applies to:

• Microsoft Visual C++ for MS-DOS, version 1.0

SUMMARY

The text below presents information in Part 7 of the README.WRI file distributed with Microsoft Visual C++ version 1.0. Setup installs README.WRI in the MSVC\HELP directory.

MORE INFORMATION

Debugging Applications That Use Toolbars

Certain video drivers contain INT 3 instructions, which were used for debugging purposes during the development of the driver but were not removed from the retail version. When a debugger is not running, these INT 3 instructions are ignored. When a debugger is running (including the Visual Workbench's integrated debugger and CodeView for Windows), an INT 3 instruction is interpreted as a breakpoint, causing program execution to stop. INT 3 instructions also interfere with the MS-Test application, which interprets an INT 3 instruction as a GP fault.

The drawing code in the toolbars provided with the Microsoft Foundation Class Library may cause certain video drivers to execute an INT 3 instruction. If you encounter this problem when debugging a program written with the Microsoft Foundation Class Library, you can safely ignore the interruption and continue executing your program, or you can change the INT 3 into a NOP instruction from within the debugger and then continue.

Converting from MFC 1.0 to MFC 2.0

When recompiling MFC 1.0 applications for MFC 2.0, makefile and source modifications may be needed. These changes are discussed in Technical Note #19 in the MFCNOTES.HLP file accessed through the MFC Tech Notes Winhelp icon in the Microsoft Visual C++ program group.

Migrating the WEP of a DLL to Foundation Class Library Version 2.0

In version 2.0 of the Foundation Class Libraries, the ExitInstance() member function of your WinApp-derived class will be called from a _WEP function provided by the Foundation Class Libraries (which in turn is called by the C++ run-time library when Windows calls the DLL's WEP). If you implemented a DLL using version 1.0 of the Foundation Class Libraries, you had to explicitly implement the _WEP function. To migrate your DLL from version 1.0 to version 2.0, you need to move your code from the old _WEP function to an override of the CWinApp::ExitInstance() function, and remove the old _WEP.

Using VBX Custom Controls

A large number of Visual Basic version 1.0 VBX custom controls have been tested and verified to work with App Studio and MFC 2.0, but the VBX you are using may not be one of them, especially if it is one not widely distributed.

Important: If you experience any of the problems identified below, please contact the developer of the VBX control to obtain information about a possible update of the control that has been verified to function with App Studio and MFC 2.0. Microsoft is actively working with VBX control vendors to ensure that VBX controls work successfully with App Studio and MFC 2.0.

Possible symptoms of a control that does not work with App Studio and MFC 2.0 are:

• repaint problems (not painting, or painting too much)
• setting property values not reflected in the control
• inability to resize the control
• control does not reflect tab order/grouping property accurately
• control does not function under Test Mode
• control cannot be properly initialized if programmatically created because it assumes that it is being loaded from a form
• Unrecoverable Application Error
• General Protection Fault
• debug kernel Fatal Exit

Debugging Dialogs or Form Views That Contain VBX Controls

When using the Visual Workbench debugger, if you set a breakpoint in a function that directly or indirectly creates a VBX control, you may get a message box stating, "The program is stopped in the debugger." If this happens, you must choose OK in the message box before the debugger will set focus on the breakpoint in your sources. You can continue debugging at this point.

This unexpected message box is displayed only when you use the Visual Workbench debugger in soft mode. This does not happen when you use the Visual Workbench debugger in hard mode or when you use CodeView for Windows.

No Debug Support for Small or Compact Model MFC Applications

You cannot build small or compact model debug MFC applications. The additional debug code exceeds the small and compact model limits of 64K code even for the a trivial MFC application. You can build small or compact model release applications using the release versions of the small or compact model libraries. If you wish to ship a small or compact model MFC application, use medium or large model (respectively) for debug builds and small or compact model for the final release build.

Using ClassWizard on the CHKBOOK Sample Program

The CCheckView class has two message handlers: OnEditCommitCheck() and OnAmountNumChange(). If you examine the class using ClassWizard and highlight OnEditCommitCheck() in the Member Functions list box, no entry is highlighted in either the Object IDs list box or the Messages list box. This is because CCheckView is derived from CFormView, and ClassWizard treats CFormView-derived classes as dialog classes rather than as view classes. As a result, ClassWizard lists only the controls in the associated dialog template and the notification messages that those controls can generate. (For example, ClassWizard highlights the notification message handled by OnAmountNumChange() and the ID of the control that generates that message.) To see what message is highlighted by OnEditCommitCheck(), use App Studio to open CHKBOOK.RC and edit the IDR_CHECKFRAME menu resource. Then invoke ClassWizard to examine CCheckView.

For more information on how ClassWizard interacts with CFormView-derived classes, see the items on CFormView in ERRATA.WRI.