Compile Visual Basic Project Action

Project

Project File

Specifies the path and file name of the Visual Basic project file that you wish to compile.

Project Name

Identifies the project in code. It can't contain periods (.), spaces, or start with a non-alphabetic character. For a public class name, the project name and class name cannot exceed a total of 37 characters.

Refresh Button

Refreshes the settings from the project.vbp file. This will overwrite the changes that you made in FinalBuilder.

Help File Name

The name of the Help file associated with the project.

Help Context ID

The context ID for the specific Help topic to be called when the user selects the "?" button while the application's object library is selected in the Object Browser.

Project Description

A user-friendly name for the project. Displayed in the References and Object Browser dialog boxes.

Fix up ActiveX references

Go through the project file and fix up any references to ActiveX controls which are not correct.

Save reference fixes to project file

Save the above fixes for ActiveX references back into the project file.

Output Executable

The full path and file name that the project will be compiled to.

Keep generated VBP

Do not delete the VBP file. Useful for review after the build, or a failed build to see what options have been set.

Compatibility

This page allows you to decide which version compatibility mode you want to use when compiling.

Do not set

Uses the settings defined within the project file.

No Compatibility

With this setting, new class ID's, new interface ID's and a new type library ID will be generated by VB each time the ActiveX component project is compiled. This will cause any compiled client components to fail (with error 429!) and report a missing reference to the 'VB ActiveX Test Component' when a client project is loaded in the VB IDE.

Use this setting to compile the initial release of a component to other developers.

Project Compatibility

With this setting, VB will generate new interface ID's for classes whose interfaces have changed, but will not change the class ID's or the type library ID. This will still cause any compiled client components to fail (with error 429!) but will not report a missing reference to the 'VB ActiveX Test Component' when a client project is loaded in the VB IDE. Recompilation of client components will restore them to working order again.

Use this setting during the initial development and testing of a component within the IDE and before the component is released to other developers.

Binary Compatibility

VB makes it possible to extend an existing class or interface by adding new methods and properties etc. and yet still retain binary compatibility. It can do this, because it silently creates a new interface ID for the extended interface and adds registration code to register the original interface ID but with a new Forward key containing the value of this new interface ID. COM will then substitute calls having the old ID with the new ID and hence applications built against the old interface will continue to work (assuming the inner workings of the component remain backward compatible!).

With this setting, VB will not change any of the existing class, interface or type library ID's, however in order that it can do so, VB requires the project to specify an existing compiled version that it can compare against to ensure that existing interfaces have not been broken.

Use this setting following the release of a component to other developers.

If you use the AutoInc Version Number, you need to save the FinalBuilder project after building for this to be saved. Alternatively, use a FinalBuilder Project variable and read the value from an ini file before compiling and then write the variable back out to the ini file after compiling.

Some important info on the "Fix up ActiveX References" setting on the Project Tab

When using Project or No Compatibility with ActiveX DLL projects, the CLSID's for those projects change with each compile or interface change (depending on the compatibility setting). This will invalidate references to those dll's in other projects. When the Fix up ActiveX References option is checked, FinalBuilder will check that the references are correct, and if not correct them. It does this by locating the type library and extracting the CLSID and comparing it to the reference entry, if they are not the same then the reference entry is corrected. This will enable FinalBuilder to compile the projects correctly, and also help you avoid the dreaded 429 Ole Automation error.