I put together a test project together with a package that I configured from one test to the next as (1)Design Only, (2)Run Time Only, (3)Design plus Run Time, respectively. IOW, the package was saved/installed 3 times as a different type each time and then tested a number of ways with the test application which takes a component from the package. The objective was to explore differences in behavior and use.

I discovered absolutely *no* difference between use and behavior of a Design Time Package vs. a Design plus Runtime and they install the same way.

"Run time only" is as expected: "Component/Install Packages" simply refuses if you navigate to the .bpl, which is what we would want.

A "Design time only" works just like the "Design+runtime". You can Build with or without the .bpl to produce either a "link with RT packages" or link with your .dcu's.

If my finding is correct, why is there even mention of a "Design Time plus Run Time" option and/or why is there "Design Time Only" and not just "Design Time"?  I notice in the old Borland manuals there is only Run Time and Design Time.

It is certainly possible I have overlooked something but would like to know what it is.

Best wishes,
gk

Garth wrote:

> I discovered absolutely *no* difference between use and behavior of
> a Design Time Package vs. a Design plus Runtime and they install the
> same way.

There is a difference.

> "Run time only" is as expected: "Component/Install Packages" simply
> refuses if you navigate to the .bpl, which is what we would want.
> 
> A "Design time only" works just like the "Design+runtime".

When installing a package into the IDE, it only cares about the "designtime" 
portion, so in that regard both types are treated equally.

> If my finding is correct, why is there even mention of a "Design Time
> plus Run Time" option and/or why is there "Design Time Only" and not
> just "Design Time"?

There really is a semantical difference.  A "Runtime only" package cannot 
be loaded by the IDE, only linked into a compiled executable.  A "Designtime 
only" package can be loaded into the IDE but cannot be linked into a compiled 
executable.  A mixed package can be both loaded into the IDE at designtime 
and linked into a compiled executable.  Most packages are typically marked 
as "Runtime and Designtime" because they do not contain designtime-specific 
code in them, only component registrations, which can be used at both design-time 
and run-time.  The only time you would create "Runtime only" and "Designtime 
only" packages is when you need to implement custom design-time editors and/or 
wizards for use in the IDE.  In which case, your component code MUST be implemented 
in a "Runtime only" package (since that code is linked into compiled executables 
and not used by the IDE itself) and the editors/wizards MUST be implemented 
in a separate "Designtime only" package (that is what the IDE uses directly) 
that requires the "Runtime only" package.

--
Remy Lebeau (TeamB)

Garth Klatt wrote:

> I put together a test project together with a package that I
> configured from one test to the next as (1)Design Only, (2)Run Time
> Only, (3)Design plus Run Time, respectively. IOW, the package was
> saved/installed 3 times as a different type each time and then tested
> a number of ways with the test application which takes a component
> from the package. The objective was to explore differences in
> behavior and use.
> 
> I discovered absolutely no difference between use and behavior of a
> Design Time Package vs. a Design plus Runtime and they install the
> same way.

There is a difference if the design-time package needs to install some
support for the component's design-time behaviour, e.g. by installing a
custom property or component editor, or some kind of wizard or other
add-on. These things make the package dependent on another package
(designIDE) that can only be used inside the IDE process. For such a
case you must create different design-time and run-time packages (the
latter does not contain the IDE support, only the component itself and
library code it may need to work at run-time).

If the component does not require such design-time support you can use
a single package to install the component into the IDE and to use it in
applications that are build with run-time packages. That is what the
Design plus Runtime setting gains you: you only have one package
project to maintain instead of two.


-- 
Peter Below (TeamB)

Thanks for the replies,

I confirmed in a subsequent experiment that it is possible to do an application "Build", producing an .exe having a component that came from a "Design time Only" package. With "Build with runtime packages" chosen, the application runs providing the system can find the .bpl and redistributables.

If you do not want your customer having your design time controls/code, simply Build your application with "Link with Runtime Packages". Supply him the .bpl (plus rtl190 and vcl190 re-distributables) and instructions for installation (it could go in his application folder).  

If you want the customer to have a fully stand-alone application (no runtime library) uncheck "Link with Runtime Packages" and put a path in Project Options  to the .pas or .dcu files for the component so the compiler or linker can find these. There is no package involved and the component code is now hard-wired in the application. You can do this with either a "Design Time Only" or  a "Design and Runtime" package as confirmed by my experiment. With either one (assuming same component(s)) you get the same
 thing when building the application. 

If I distribute a "Design Time Only" package the customer can install it to his IDE and develop applications with the components, producing stand-alones or runtime linked applications (he'll also need my .dcu's for the components if he wants to build stand-alones) - just as if I gave him a "Design plus Runtime" package.

Sorry to belabor this but it's very interesting.

best wishes,
gk.


> {quote:title=Peter Below wrote:}{quote}
> Garth Klatt wrote:
> 
> > I put together a test project together with a package that I
> > configured from one test to the next as (1)Design Only, (2)Run Time
> > Only, (3)Design plus Run Time, respectively. IOW, the package was
> > saved/installed 3 times as a different type each time and then tested
> > a number of ways with the test application which takes a component
> > from the package. The objective was to explore differences in
> > behavior and use.
> > 
> > I discovered absolutely no difference between use and behavior of a
> > Design Time Package vs. a Design plus Runtime and they install the
> > same way.
> 
> There is a difference if the design-time package needs to install some
> support for the component's design-time behaviour, e.g. by installing a
> custom property or component editor, or some kind of wizard or other
> add-on. These things make the package dependent on another package
> (designIDE) that can only be used inside the IDE process. For such a
> case you must create different design-time and run-time packages (the
> latter does not contain the IDE support, only the component itself and
> library code it may need to work at run-time).
> 
> If the component does not require such design-time support you can use
> a single package to install the component into the IDE and to use it in
> applications that are build with run-time packages. That is what the
> Design plus Runtime setting gains you: you only have one package
> project to maintain instead of two.
> 
> 
> -- 
> Peter Below (TeamB)

Hello Garth,

> Thanks for the replies,
> 
> I confirmed in a subsequent experiment that it is possible to do an
> application "Build", producing an .exe having a component that came
> from a "Design time Only" package.

A "Designtime only" package is meant for use only by the IDE.  It SHOULD 
NOT be linked into an executable.  Even if it is *technically* possible to 
do, it is *semantically* wrong, and goes against the IDE's Terms of Service 
anyway, which forbids design-time code to be linked into run-time executables.

> If you do not want your customer having your design time controls/code,
> simply Build your application with "Link with Runtime Packages".

Design-time packages should be compiled with Runtime Packages enabled, so 
they can share the same RTL/VCL that the IDE itself uses. 

Run-time packages may or may not need to be compiled with Runtime Packages 
enabled, depending on your actual needs.

> Supply him the .bpl (plus rtl190 and vcl190 re-distributables) and
> instructions for installation (it could go in his application folder).

Packages are version-specific, so you would have to provide .dcus and/or 
..bpi/.bpl files for every IDE version you want to support.

> If you want the customer to have a fully stand-alone application (no
> runtime library) uncheck "Link with Runtime Packages" and put a path
> in Project Options  to the .pas or .dcu files for the component so the
> compiler or linker can find these.

You should compile the .pas/.dcu files into a Runtime package, and then link 
that package into projects.  If you have design-time editors for the components, 
you MUST do that.

If you don't want the users to have access to the component source, giving 
them .dcu files is OK, but you are again restricted to versioning limitations.

> There is no package involved

There should be.

> and the component code is now hard-wired in the application.

It would be if you provided a Runtime Package that has a .bpi file associated 
with it.  The .bpi would be statically compiled into projects that have Runtime 
Packages disabled, and the .bpl would be dynamically linked to in projects 
that have Runtime Packages enabled.

You are circumventing the system, instead of using it the way it is meant 
to be used.

> You can do this with either a "Design Time Only" or a "Design and Runtime"
> package as confirmed by my experiment.

A "Designtime only" package SHOULD NEVER be linked into an executable.

A "Designtime and Runtime" package CAN be linked into an executable, but 
ONLY if it does not contain any design-time code in it (other than RegisterComponents(), 
which is implemented in a runtime package and not in a designtime package).

> With either one (assuming same component(s)) you get the same thing when
> building the application. If I distribute a "Design Time Only" package the
> customer can install it to his IDE and develop applications with the components,
> producing stand-alones or runtime linked applications (he'll also need my
> .dcu's for the components if he wants to build stand-alones) - just as if
> I gave him a "Design plus Runtime" package.

The *correct* solution is to provide separate Runtime and Designtime packages, 
don't provide the .dcu files, and do not provide a do-all "Designtime only" 
package - which would be a violation of the "designtime only" semantic.

--
Remy Lebeau (TeamB)

Thanks Remy,

I appreciate the thorough response and have copied the text of this conversation into my "notes" folder for future reference.

Your reply has been marked with the full stars.

Best wishes,
gk



> {quote:title=Remy Lebeau (TeamB) wrote:}{quote}
> Hello Garth,
> 
> > Thanks for the replies,
> > 
> > I confirmed in a subsequent experiment that it is possible to do an
> > application "Build", producing an .exe having a component that came
> > from a "Design time Only" package.
> 
> A "Designtime only" package is meant for use only by the IDE.  It SHOULD 
> NOT be linked into an executable.  Even if it is *technically* possible to 
> do, it is *semantically* wrong, and goes against the IDE's Terms of Service 
> anyway, which forbids design-time code to be linked into run-time executables.
> 
> > If you do not want your customer having your design time controls/code,
> > simply Build your application with "Link with Runtime Packages".
> 
> Design-time packages should be compiled with Runtime Packages enabled, so 
> they can share the same RTL/VCL that the IDE itself uses. 
> 
> Run-time packages may or may not need to be compiled with Runtime Packages 
> enabled, depending on your actual needs.
> 
> > Supply him the .bpl (plus rtl190 and vcl190 re-distributables) and
> > instructions for installation (it could go in his application folder).
> 
> Packages are version-specific, so you would have to provide .dcus and/or 
> .bpi/.bpl files for every IDE version you want to support.
> 
> > If you want the customer to have a fully stand-alone application (no
> > runtime library) uncheck "Link with Runtime Packages" and put a path
> > in Project Options  to the .pas or .dcu files for the component so the
> > compiler or linker can find these.
> 
> You should compile the .pas/.dcu files into a Runtime package, and then link 
> that package into projects.  If you have design-time editors for the components, 
> you MUST do that.
> 
> If you don't want the users to have access to the component source, giving 
> them .dcu files is OK, but you are again restricted to versioning limitations.
> 
> > There is no package involved
> 
> There should be.
> 
> > and the component code is now hard-wired in the application.
> 
> It would be if you provided a Runtime Package that has a .bpi file associated 
> with it.  The .bpi would be statically compiled into projects that have Runtime 
> Packages disabled, and the .bpl would be dynamically linked to in projects 
> that have Runtime Packages enabled.
> 
> You are circumventing the system, instead of using it the way it is meant 
> to be used.
> 
> > You can do this with either a "Design Time Only" or a "Design and Runtime"
> > package as confirmed by my experiment.
> 
> A "Designtime only" package SHOULD NEVER be linked into an executable.
> 
> A "Designtime and Runtime" package CAN be linked into an executable, but 
> ONLY if it does not contain any design-time code in it (other than RegisterComponents(), 
> which is implemented in a runtime package and not in a designtime package).
> 
> > With either one (assuming same component(s)) you get the same thing when
> > building the application. If I distribute a "Design Time Only" package the
> > customer can install it to his IDE and develop applications with the components,
> > producing stand-alones or runtime linked applications (he'll also need my
> > .dcu's for the components if he wants to build stand-alones) - just as if
> > I gave him a "Design plus Runtime" package.
> 
> The *correct* solution is to provide separate Runtime and Designtime packages, 
> don't provide the .dcu files, and do not provide a do-all "Designtime only" 
> package - which would be a violation of the "designtime only" semantic.
> 
> --
> Remy Lebeau (TeamB)