Jump to content
Bill Meyer

Avoiding use of BPLs

Recommended Posts

I have a large project I am moving from D2007 to Tokyo. I have reached the point of putting an executable up on a server for QA to exercise, and learned then that it requires the deployment of a number of BPLs.

BPL_options.thumb.png.f3dc7e68714320870b216b535ea823b3.png

As far as I understand it, these settings should make that unnecessary, However, after building, I see this:

BPL_List.png.baa14b51482c5a12a138ee3230e35273.png

 

Any guaranteed solution for the problem?

Share this post


Link to post

What baffles me is the appearance of designide in the used packages list. That one is supposed to be used in design time packages only.

Share this post


Link to post
30 minutes ago, Uwe Raabe said:

What baffles me is the appearance of designide in the used packages list. That one is supposed to be used in design time packages only.

It is added in the options with -LUDesignIde because of a home-grown component which requires the app to reference the DesignEditors unit. More than that, I can't explain, as I am too far out of my element there.

Share this post


Link to post
40 minutes ago, Bill Meyer said:

It is added in the options with -LUDesignIde because of a home-grown component which requires the app to reference the DesignEditors unit. More than that, I can't explain, as I am too far out of my element there.

You've probably answered the question yourself. DesignIde brings the others with it. Now your exe will link to different instances of rtl and vcl I think. Statically linked rather than runtime packages. Which might be a problem.

 

Solution likely to involve getting rid of dependency on DesignIde. 

  • Like 1

Share this post


Link to post
3 minutes ago, David Heffernan said:

You've probably answered the question yourself. DesignIde brings the others with it. Now your exe will link to different instances of rtl and vcl I think. Statically linked rather than runtime packages. Which might be a problem.

 

Solution likely to involve getting rid of dependency on DesignIde. 

One might (foolishly) think that in the help article which explains using -LUDesignIde some mention could have been made of the consequence. Thanks.

Edited by Bill Meyer
  • Like 1

Share this post


Link to post
19 minutes ago, Bill Meyer said:

One might (foolishly) think that in the help article which explains using -LUDesignIde some mention could have been made of the consequence. Thanks.

This should fail for exe as since Delphi 7 it can be only used in packages or dlls not executables.

Share this post


Link to post
13 minutes ago, Lajos Juhász said:

This should fail for exe as since Delphi 7 it can be only used in packages or dlls not executables.

In that case, the dependency on DesignIde must be eliminated completely, not merely isolated to the realm of the component in question. If my understanding of the issue is correct. Or is this the issue which requires the separation of run time and design time component packages? I suppose that must be the real issue here.

Edited by Bill Meyer

Share this post


Link to post
1 hour ago, Bill Meyer said:

Or is this the issue which requires the separation of run time and design time component packages?

Design-time code (property editors, component editors, IDE wizards, etc) are simply not allowed in runtime executables, period.  So, your home-grown component needs to be implemented in a runtime-only package, and any code that relies on the DesignIDE package needs to be implemented in a designtime-only package that "requires" the runtime-only package.  Your component should have no concept of design-time whatsoever (outside of things like the csDesigning flag in its ComponentState property, the CM_DESIGNHITTEST message, etc).  If that is not the case, then the component is not architectured properly.

  • Like 2

Share this post


Link to post
2 minutes ago, Remy Lebeau said:

Design-time code (property editors, component editors, IDE wizards, etc) are simply not allowed in runtime executables, period.  So, your home-grown component needs to be implemented in a runtime-only package, and any code that relies on the DesignIDE package needs to be implemented in a designtime-only package that "requires" the runtime-only package.  Your component should have no concept of design-time whatsoever (outside of things like the csDesigning flag in its ComponentState property, the CM_DESIGNHITTEST message, etc).  If that is not the case, then the component is not architectured properly.

Thanks. I am getting there. 

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×