Libraries / packages


I need to clear some doubts that I've about libraries:
1. What is the .Bpl and .Dcp files used for, because if I put the USES clause and write there the .Pas file that I use in the package, I don't need these package files? In what case I need them?
2. If I register some component in the VCL, why do I've to refer the USES clause with the .PAS file, to be able to get access to a class that it was registered by this component?
3. What is the best way to use a package? Design time / Run Time? Load and Unload them in code? Give me some examples.
Thank you.
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

.DCP files are used to create the .BPL files.  BPL files are simply DLLs with specific hooks that are used by Delphi to access data within them.  Essentially, DLL's which implement specific public functions in order to use used by the IDE.

As far as your question, I believe that whether they are used at runtime depends on how you compile your project.  The Packages tab in the Project Options specifies whether you want to compile your project to use runtime packages.  If selected, binaries for units contained within packages will not be compiled into your EXE/DLL.  If it is not selected, then the binaries will be compiled into your EXE/DLL, ready for local use.  It's simply a way of putting common binary code into packages, and then applications can reduce their size by using the common code in a shared binary.

I'm not sure I understand the second question.  I think if you want to use a class, you have to have it's unit in the USES clause, reagrdless of whether it's registered or not.  Registering a component allows the IDE to be aware of it, and support it via the component palette/Object explorer/etc.

Personally, I haven't found a compelling reason to use runtime packages.  However, I have found use in designing a lot of core code into packages, to help enforce specific design specifications in recent jobs.  Also, consider separating runtime package code from designtime package code (ie, what get's installed in Delphi itself).  I've worked on projects where they had 12 packages which had to be added to Delphi in a specific order (most relied on other packages), and this was problematic remembering the order.  I've achieved the same end result in another project by defining all the runtime code in multiple runtime-only packages.  Then defined a single design-time package which referenced all the runtime-packages.  This meant only loading a single package within the IDE.

Hope this helps,

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial

DCP and BPLs are two sides of the same boat: packages.
DCP ones are used at DESIGN TIME, when you need to install an
expert - for example.
BPL are used at RUN TIME, when you need to actually use a
component, to say one.

BPLs are born out of DLLs in order to simplify the process of distributing
components. Thus, BPLs can actually be used to include plain functions in
addition to forms, components and whatever Delphi class you want.

You will mainly use packages to deploy components, unless you have a
REALLY huge application, in that case the use of runtime packages may be a
remarkable plus.

Please bear in mind the versioning problems: when you recompile an exe
that uses runtime packages with newer packages' versions, you shall
redistribute the modified packages along with the new EXE.


lfgmartinsAuthor Commented:

BPL are runtime? But when I go menu component, install packages I see there lots of .BPL as design time packages. I’ve installed a component, not mine, to the VCL just by opening the package then installed it. I don’t know how it worked? One of the files has a register component routine, is because of that. How did the package know that?
How is a DCP design time? What are the differences between them?
The thing is that I comprehend the unit package ( the .PAS file) and why is used for. I know that when I compile a .DPK I generate a .DCP and a .BPL. Apparently I don’t need these files to run my application? When do I need these files? Isn’t a .PAS file that I put in the USES or do I’ve to use a DCP or BPL?
OWASP: Threats Fundamentals

Learn the top ten threats that are present in modern web-application development and how to protect your business from them.

I've lifted this from the Delphi Help:

The following table lists the files produced by the successful compilation of a package.

A binary image containing a package header and the concatenation of all DCU files in the package. A single DCP file is created for each package. The base name for the DCP is the base name of the DPK source file.

A binary image for a unit file contained in a package. One DCU is created, when necessary, for each unit file.

The runtime package. This file is a Windows DLL with special Delphi-specific features. The base name for the BPL is the base name of the DPK source file.

It was always my understanding that the package compilation process concantenated the DCU's to form the DCP.  The DCP is used to create the BPL.

I think the BPL file is both runtime and designtime.  Specifically, the BPL itself defines whether it is runtime only, design-time only or both.  This is defined in the Package options dialog box.  But, when you go to add a package to your IDE, you're adding in a BPL, not a DCP.
lfgmartinsAuthor Commented:

Thanks for all your help.
Could you clearify me what you've written in this paragraph. "" I've worked on projects where they had 12 packages which had to be added to Delphi in a specific order (most relied on other packages), and this was problematic remembering the order.  I've achieved the same end result in another project by defining all the runtime code in multiple runtime-only packages.  Then defined a single design-time package which referenced all the runtime-packages.  This meant only loading a single package within the IDE. ""

I think it's a great idea, but I don't fully understand it. Could give me a simple example or something that helps?
I'll try. :)

For example.  I have 3 components that I want to use in my IDE.  ComponentA is in PackageA.  ComponentB is in PackageB (and ComponentB uses ComponentA).  ComponentC is in PackageC (and ComponentC uses ComponentB).  All three packages have been defined as being for both runtime and designtime use.

If want to load my components into my Delphi IDE, I need to first install PackageA, then PackageB then PackageC.  Installing in any other order will not work.  As the number of packages grow and the relationships become less obvious, this is just a usibility issue with your developers.

An alternate approach would be as follows:

Change PackageA, PackageB and PackageC to runtime-only packages.  Then, define a new package, called PackageDesign.  PackageDesign is defined as design-time only, and uses PackageA, PackageB and PackageC.  PackageDesign simply contains the units required to register components, etc (this logic doesn't need to be defined in the same unit as the component).  Now, anyone wanting to use my components have 4 packages, but only need to load one into the IDE.  My IDE-specific logic is separated from my runtime logic.  I'm fairly certain that this is how Borland segments their runtime/designtime packages (why some packsges go into the Borland subdirectories and some go into Windows directories ... but I've never seen the Borland source so don't hold me to the fire on this statement).

Hope this helps,
lfgmartinsAuthor Commented:

You've helped me a lot but just tell me more this.
How do I develop the PackageDesign? With LoadPackage() or by the USES clause and including the package .PAS? After open the package I register the components with RegisterComponents, in 4 register procedures?
Well, define your components as you normally do.  But, what you need to do is define your DPK files (DPK files are to a package, what a DPR file is to an application/libray).  The DPK file will define which Units it stores, as well as whether it's a runtime/designtime/both package.  If you have runtime-only and design-time only packages, then you'll have a single unit (in the design-time package) which will contain all the RegisterComponent calls.

So, once the packages are compiled, you simply just load them into the IDE.  They will be available.

To get an application to use packages, go to it's Options dialog and define it so you compile using runtime packages (use the Packages tab in the Project Options dialog).  That's it.  Your application doesn't need to manually load the packages... it's handled automatically.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.