lfgmartins
asked on
Libraries / packages
Hi,
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.
Luis
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.
Luis
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Hi,
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?
Thanks,
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?
Thanks,
I've lifted this from the Delphi Help:
The following table lists the files produced by the successful compilation of a package.
DCP
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.
DCU
A binary image for a unit file contained in a package. One DCU is created, when necessary, for each unit file.
BPL
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.
The following table lists the files produced by the successful compilation of a package.
DCP
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.
DCU
A binary image for a unit file contained in a package. One DCU is created, when necessary, for each unit file.
BPL
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.
ASKER
EdHillmann,
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?
Luis
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?
Luis
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,
Ed
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,
Ed
ASKER
Great,
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?
Regards,
Luis
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?
Regards,
Luis
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.
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.
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.
HTH,
Andrew