Packages Versus DLLs

   

---

A Package guarantees that extensions, such as __published and protected property members and the __property keyword for a property, can be supported by the class. These specific extensions are what turn classes into components and, through registration, allow components to be leveraged by the C++Builder IDE at design time; allowing property values to be tweaked using the Object Inspector. The bottom line is that within C++Builder and Delphi (and Kylix), a Package can be more desirable than a DLL due largely to the flexibility a VCL provides.

NOTE

To dynamically load a Package at runtime, you would use LoadPackage() instead of LoadLibrary() and FreePackage() instead of FreeLibrary() .

Although there are many advantages to using a Package within C++Builder and Delphi, a disadvantage is that other development tools cannot use a VCL Package because its constructs are specific to C++Builder or Delphi. A Visual C++ application, for instance, will not be able to load and use a Package because it doesn't understand published and protected members of a class. Packages are good for making custom components that are available through the IDE as well as at runtime. Standard DLLs are good for providing reusable functionality that can be used by almost any application, no matter what development tool was used to build it.

Therefore, if you're thinking of supporting applications that might be developed under Visual C++ as well as C++Builder, you should choose to develop a DLL with an interface (header file) that doesn't use and require the VCL. Note that this doesn't preclude developing a DLL that uses a VCL component, such as TForm, within the source code. It's just that the VCL elements cannot be exposed or required by the header file, which is the interface often used by the calling application.

Steps for Creating a Package

Assuming you're developing a component to be used only by C++Builder applications, let's quickly examine how to build a Package. The easiest way to create a Package is to select File, New. Then, choose Package from the New Items dialog, and then press OK (see Figure 16.11).

Figure 16.11. The New Items dialog box.

Following these steps, a Package project dialog will be displayed showing the files that were generated associated to the project as illustrated in Figure 16.12.

Figure 16.12. Package project dialog box.

If you open the Package1.cpp file identified in the dialog box, you'll see a familiar code skeleton for the package. This is shown in Listing 16.13.

Listing 16.13 The DLL Entry Point Function for a Package

 #include <basepch.h>  #pragma hdrstop  #pragma package(smart_init)  //                                      - //   Package source.  //                                      - #pragma argsused  int WINAPI DllEntryPoint(HINSTANCE hinst, unsigned long reason, void*lpReserved)  {          return 1;  } 

Notice the DLL entry point function within this code? It looks exactly like a DLL! The only difference is that instead of windows .h or vcl.h included at the top of the source, the basepch.h header file is included instead. This header file points to the core header file that includes VCL and CLX headers, which is what's needed to construct a Package. Also, when we compile and build the package, a .bpl file will be generated instead of a .dll file. This is as far as we really need to go regarding Packages. Any further discussion would center on VCL-component development, which is not in the scope of this chapter. For more information on how to build and use Packages featuring VCL components see Chapter 4, "Creating Custom Components."

---

Top