VC++ README.WRI Part 2-Visual Workbench (3 of 3)

ID: Q97539

The information in this article applies to:

SUMMARY

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


MORE INFORMATION

Using Class Wizards to Add Files to a Project

After you add a file to a project using the Class Wizard, use the Rescan All Dependencies command available on the Project menu. This will update the file dependencies to reflect the added file.

Resources Dialog Box

If you use the AppWizard to create a new skeleton application and then open the Resources dialog box by choosing the Project command from the Options menu, the "Custom Options" field will contain garbage characters. The extra characters will not be passed to the Resource Compiler. If you choose OK, and open the dialog again, the extra characters will be gone.

Automatic Use of Precompiled Headers

In the description of the Automatic Use of Precompiled Headers (/YX) option (Chapter 9 of the "Visual Workbench User's Guide," pages 138-141), it is stated that the /Fp option is not supported in Visual Workbench. The /Fp option is actually supported, but not on a per-file basis as it is on the command-line. It is also stated that a file named MSVC.PCH is always used as the precompiled header file. In fact, the /Fp option is automatically used to name the precompiled header file to match your project name.

When you select Automatic Use of Precompiled Headers, /Fp is inserted in the Other Options dialog box (Custom Options category) followed by the name of your project with an extension of .PCH. This renames MSVC.PCH to match your project name and allows you to have more than one project in a directory (which is a common occurrence when developing .EXE and .DLL applications). The rules for creating and using precompiled header files using /YX with /Fp are the same as are described on pages 138-141 for using /YX without /Fp. The only difference is that Visual Workbench uses a file named project.PCH (where project is your project name) instead of MSVC.PCH.

Debug Options: Full (Using Program Database)

The description of the Full (Using Program Database) option in the Debug Options category on page 128 of the "Visual Workbench User's Guide" states that the /Zi option creates a special database file named MSVC.PDB. In Visual Workbench, the selection of Full (Using Program Database) automatically adds the option /Fd"<project>.PDB" (where <project> is your project name) as well as /Zi. This renames the database filename to match your project name.

Setting WndProc Breakpoints

Declarators for Windows functions must use the ANSI form for the procedure to appear in the WndProc drop-down list in the Break- points dialog box. You should also put the ANSI function prototype in the header file for the source file containing the function.

If your source code includes function declarators that have the form in use prior to the form specified by the ANSI standard, the compiler does not generate type information for use with the debugger.

The pre-ANSI (or old-style) declarators have the following form: 

   LRESULT FAR PASCAL MyWndProc ( hwnd, wMsg, wParam, lParam )
   HWND hwnd ;
   WORD wMsg ;
   WORD wParam ;
   LONG lParam ;
   {

   }
An ANSI declarator for the same function has the following form: 

   LRESULT FAR PASCAL MyWndProc ( HWND hwnd, WORD wMsg, \ 
                  WORD wParam, LONG lParam )
   {

   }

Setting the WinExclusive flag in SYSTEM.INI

The WinExclusive flag in the [386Enh] section of the SYSTEM.INI file should not be set to the value 1. If it is, you will get an internal error when you build in the Visual Workbench, and a message explaining that the Visual Workbench timed out waiting for WINTEE.EXE to start.

Using VSAFE While Building

You should not use the VSAFE utility provided with MS-DOS version 6 while you are building an executable file in the Visual Workbench. The Visual Workbench will appear to hang when VSAFE detects an executable file changing during the link process.

Using the Visual Workbench on a Pen Computer

Compiling, linking, or binding resources from the Visual Workbench may disable the pen on a pen computer. The pen will be enabled after exiting the Visual Workbench.

MSVC Command Line Options

The following command line options may be useful if you encounter problems such as your system or build hangs while building an application using the Visual Workbench. Such problems may be caused by interaction between the Visual Workbench and WINTEE utility that handles communication between the Visual Workbench and the Visual C++ tools.

To use the Visual Workbench command line options, edit the Command Line field in the Program Item Properties dialog box associated with the Visual Workbench in the Windows Program Manager.

The Visual Workbench uses the following command line options:

/V - This option causes the WINTEE utility to run in a visible windowed MS-DOS box. Ordinarily the WINTEE utility is not visible when it is running. Using the /V option allows you to see the output of the tools used when you build your application. Normally the output from the build tools appears in the Output of the Visual Workbench.

/C - This option causes memory to be compacted before any Visual C++ tools are used. Using the /C option may increase the memory available to the tools, but will increase the time required to build.

/M - This option will cause the WINTEE utility to run every time you start a build. Using the /M option will increase the time required to build, but may solve problems caused by some system configurations. Normally WINTEE is started the first time you build within the Visual Workbench, and remains in memory until you exit the Visual Workbench. When you use the /M option, WINTEE exits after a build is complete, freeing resources to the system.

Additional query words: 1.00 


Keywords          : kb16bitonly 
Version           : 
Platform          : 
Issue type        :

Last Reviewed: July 30, 1999