This action provides an interface to the VB6 compiler. This action maintains the Version info and some other settings separate from the visual basic project file (.vbp). Before running the VB compiler, FinalBuilder creates a temporary .vbp file using the settings from the FinalBuilder action and from the actual project.vbp file.
Specifies the path and file name of the Visual Basic project file that you wish to compile.
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.
Refreshes the settings from the project.vbp file. This will overwrite the changes that you made in FinalBuilder.
The name of the Help file associated with the project.
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.
A user-friendly name for the project. Displayed in the References and Object Browser dialog boxes.
Go through the project file and fix up any references to ActiveX controls which are not correct.
Save the above fixes for ActiveX references back into the project file.
The full path and file name that the project will be compiled to.
Do not delete the VBP file. Useful for review after the build, or a failed build to see what options have been set.
This page allows you to decide which version compatibility mode you want to use when compiling.
Uses the settings defined within the project file.
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.
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.
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.