Creating, Compiling, and Installing Packages

   

Three types of packages can be generated to create custom components: design time only, runtime only, and dual design time/runtime packages. When you distribute components, you should endeavor to always distribute a design time only and runtime only package pairtwo packages. When you are still developing a component or components , the dual package is a reasonable and convenient choice.

In addition to deciding how to structure your packages, you must adopt a sensible naming convention for both the units inside your package and the components themselves . You must also decide if you want your components to be usable in different versions of the compiler.

Packaging Components

Getting ready to create a component or components requires you to have a package within which they will be compiled. You need to start with a project group to hold your package because any package you create will be within the current project group, and you usually do not want a package to be part of the application project group you are currently using. Creating a project group is accomplished by picking File, New from the IDE menu, and then, from the New tab of the resulting dialog, picking Project Group . Next, pick File, New from the IDE menu and pick Package from the New tab of the dialog.

The New tab of the File, New dialog is shown in Figure 4.1.

Figure 4.1. View of the items in the File New Dialog.

graphics/04fig01.gif

Next, you need to identify the type of package you are creating. Pick Options from the pop-up menu on the package window, as shown in Figure 4.2.

Figure 4.2. Getting ready to edit the package type.

graphics/04fig02.gif

This produces a dialog where you can specify the type of package, as shown in Figure 4.3.

Figure 4.3. Setting the package type.

graphics/04fig03.gif

For most package development, it is convenient to create a dual design time, runtime package. However, later, when preparing your package for distribution, you might want to put your code into separate design time and runtime packages. This will be the case when you have special property editors or other facilities that you need to provide to those using the component (see the following section on component distribution and Chapter 5, "Creating Property and Component Editors").

When you are satisfied that your components are working properly, you should make sure that they are packaged correctly. The most correct approach involves separating the design time and runtime code. The correct way to do this using packages involves creating a minimum of two packages: a runtime-only package and a design time-only packagea runtime-only/design time-only package pair. This requires two steps:

  1. Create a runtime-only package containing only the source of your component(s). Do not include any code to register the component(s) or any code for the design time interface of the component(s) (such as code for property and component editors).

  2. Create a design time-only package containing only the registration code and optionally any design time interface code for your component(s). Do not include any source code for your component(s). Instead, add the import library (the .bpi file) of the component(s) run time-only package to the package's Requires list.

The design time package is the package installed into the IDE. Figure 4.4 illustrates the relationship between the two packages.

Figure 4.4. A runtime-only/design time-only package pair.

graphics/04fig04.jpg

It can be seen in Figure 4.4 that the design time package is only used to create a .bpl file for installation into the IDE. The runtime package is used to create the files that will actually be used by an application. In reality, one or more runtime-only packages could be used in conjunction with a single design time-only package (in other words, appear in the Requires section of the design time-only package). All code, save registration code, can be removed from the design time-only package, effectively making the design time-only package a registration package.

For comparison, a dual design time/runtime package is shown in Figure 4.5.

Figure 4.5. A dual design time/runtime package.

graphics/04fig05.gif

The code required for registration and for property and component editors will be unnecessarily included in any applications that use a dual package such as that shown in Figure 4.5. For simple packages with no property or component editors, this might be acceptable. Testing a component or set of components using a dual package is also generally more convenient, however, you can simplify the effort by including both design time and runtime packages in the same program group. Don't forget to save the program group and the package projects generally into the directory where you are keeping the code for the components they contain.

Dual packages add some development complexity. Here are the considerations you need to keep in mind.

The runtime-only package will be the first package created. To specify that a package is a runtime-only package, check the Runtime Only option on the Description page of the package's Options dialog box. This package should contain only the source for the component(s).

Any import libraries ( .bpi files) required by the component(s) should be added to the Requires list for this package project. Care should be taken to only add those import libraries that are necessary for a successful build. Remember, packages that are referenced in the Requires list are linked during compile time to any future application that uses this package and one or more units from the Required package.

After the runtime-only package is successfully built, you will have three files (unless you indicated you did not want to create a .lib file by having unchecked the Generate .lib File option on the Linker page of the package's Options dialog): a .bpl file, a .bpi file, and a .lib file. Make sure all three are present because all are required. The .lib file might not always be needed, but it should be available for those times when it is desired to statically link your components to an application (and many developers prefer the distribution simplicity of a statically linked application).

After the runtime-only package is built, and you have an import file available, you can now create the design time-only package, which depends on the runtime package to provide the features of your component. This package will contain your registration code and any special property and component editors that your components need. The Requires section includes the import library of the runtime-only package. If there are no special component or property editors for this package, you are only required to write the registration code. (Property editor and component editor creation is covered in Chapter 5.)

Compiling and Installing Packages

Package projects can be compiled in the normal fashion and produce the normal compiler and linker output. Packages are essentially fancy DLLs under Windows and fall into a similar category under Linux.

The package can be installed into the IDE in either of two ways. The first way is to compile the package with the Install entry on the package project's pop-up menu. The second way is to compile the package normally, and then pick Install from that menu, in which case, Install will simply add the package without recompiling.

A third way also exists, which is the one typically used by the recipients of your packagethat is, picking Install Packages from the IDE Components menu.

The Visual Component Library (VCL) is an extremely powerful tool, and putting together an application is very easy using the many stock components, classes, and methods that C++Builder provides. However, in some situations you might find that a component doesn't quite provide the capabilities you need. The ability to write and modify components gives you a distinct advantage over other programming languages and is one reason why C++Builder is the tool of choice for many programmers around the world. Creating custom components will give you an insight into how the VCL works and increase your productivity with C++Builder. Judging by the number of commercial component sites on the Internet, it can be a profitable exercise as well.


   
Top


C++ Builder Developers Guide
C++Builder 5 Developers Guide
ISBN: 0672319721
EAN: 2147483647
Year: 2002
Pages: 253

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net