ZComponent.bpl and designide.bpl

wietsehagoort · Post by **wietsehagoort** » 28.08.2006, 12:48

I'm currently building an application which uses bpl's.
This means I have to deploy all bpl's on which my bpl's depend.

My application uses Zeos, so I need to deploy the Zeos bpl's to.

The problem is that my application depends on ZComponent.bpl (which is not strange), and ZComponent.bpl depends on designide.bpl.
When deploying an application you're not allowed to deploy designide.bpl.

So the question is: Why is ZComponent.bpl never splitted in two bpl's?

Post by **mdaems** » 28.08.2006, 13:40

Hi Wietse,

Can you explain me (a novice in bpl stuff) what should be done to avoid this dependency? Even more, can you do the necessary modifications?

Can't you just leave out the designide.bpl? Is there an alternative to this bpl that can be deployed?

Mark

wietsehagoort · Post by **wietsehagoort** » 28.08.2006, 13:47

The current ZComponent.bpl is a runtime and designtime bpl.
It's not possible to leave out a bpl, because a bpl will only load if all depencies are available.

I will try to make the modifications and post them in this topic.

Post by **mdaems** » 28.08.2006, 15:18

Oeps Wietse,

I forgot to ask if you are using the most current version as I only maintain that version.
If you do use 6.5.1 and can use SVN that would be very nice.
Can you post the changes to the 'user patches' forum of version 6.5.1?
If you can't (or don't want to) use SVN please start from the latest build om http://users.telenet.be/mdaems

For simple practical discussion you can contact me in dutch using private messages.

Mark

gto · Post by **gto** » 28.08.2006, 19:43

Hello!

First, bpl is a Borland extension for a library package. Imagine a bpl like a Super-DLL, where the code of required 3rd-party lives. Then your application will become MUCH more small, but will require the bpl packages to run. A problem: The needing of bpl's to run, if not take with care, can lead you to a "DLL hell", but with bpl's. A solution: If one single package of your application has an update, there's no need to rebuild and send to client all the stuff, only the exactly package updated.

After Delphi version 5, Borland changed the internal structure of component editors, I think to be more compatible with the new CLX lib (delphi 6 and up).

The changes reflect directly into property editors (like Zeos ones), where Borland recommends to: Split the registration packages into two: One for runtime and other for designtime. This will avoid requiring packages that are only needed through designtime (the editors) into runtime environment. Even more, delpoy DesignIDE.bpl with your application is ilegal!

http://bdn.borland.com/article/0,1410,27717,00.html

Then, the solution, direct form the article above:

In 99.99% of the cases this is actually very easy to fix. Your runtime code isn't actually using the design-time code; things just are not properly segregated. The segregation lines are fairly simple, however.

The design-time package should include:

1. All registration statements.
2. All property editors.
3. All Component editors.
4. Should require DesignIDE and each runtime package that holds the components themselves.

The runtime package should include:

1. The components themselves only.
2. Optionally, any forms the editors may use IF the component can call the form itself at runtime

Translating to Zeos, split ZComponent into two distinct packages.

One with ZComponentReg, ZPropertyEditor and ZUpdateSqlEditor (units that need DesignIDE, or the "Design Time Units")
Other with the rest (the "Run Time Units"), whitout needing of DesignIDE.
Doing this, your application will need only "ZComponentRuntime.bpl" to compile and run.

That's theory, if I get some spare time later, I'll split it and post here

wietsehagoort · Post by **wietsehagoort** » 05.09.2006, 10:58

I splitted the ZComponent.bpl into ZComponent.bpl and ZComponentDesign.bpl.

The ZComponent.bpl is now runtime only and the ZComponentDesign.bpl is designtime only. This solves the runtime depency on designide.bpl.

I have added the changes as an attachment for the delphi 7 packages.
It should be easily applied to the other packages, because it just isn't a big issue (technically spoken).

When installing this, you should uninstall all the old Z*.bpl in your 'Component->Install packages' menu.
Then you should recompile all the packages and only install the ZComponentDesign.bpl.

The attached code is a change of zeos 6.5.1 (rev 98 I thought).

Post by **mdaems** » 06.09.2006, 10:53

Hi Wietse,

I committed your change to SVN testing branch. I hope other people will do this split for other Compiler versions.
Can you please check the new SVN version and confirm if it works fine? Did you package your application now using the bpl's?

Mark

btrewern · Post by **btrewern** » 06.09.2006, 13:56

This will need documentation.

I just looked on the Testing SVN branch to see if it had been done but can't understand the xml format. Any tips?

Regards,

Ben

gto · Post by **gto** » 06.09.2006, 14:47

wietsehagoort, have you checked all that ON/OFF value settings? I've seen that they're mostly ON into original file, but in your split they change a bit.
That switches aren't very clear to me, can't suggest what should be what

wietsehagoort · Post by **wietsehagoort** » 08.09.2006, 14:31

gto, you're right about the switches.

I suggest that we keep the old switches which means:
- The line with {$RANGECHECKS ON/OFF} can be deleted in both files.
- {$OVERFLOWCHECKS OFF} and {$STACKFRAMES OFF} in ZComponentDesign.bpl should be ON.

mdaems, the packages are currently running in a production environment (with zeos 6.1.5) and I don't have any problems.

Post by **mdaems** » 11.09.2006, 07:52

Hi All,

I've removed this switches in my current package versions for Delphi 7. On a future commit it will be added to the repository version.
Someone using D2005 or D2006? Please go on and do the split there as well. I'll add it asap. (Post to user patches for 6.5.1)

Mark