Fuss over Runtime and Design Time packages in Delphi

Question

I have seen that most of the components (VCLs) in Delphi are split in two parts.
1) DesignTime Package
2) RunTime Package

Why all this fuss. What difference does it make if both RunTime and DesignTime packages are united into one single Package?

I have never really been able to understand this separation logic.

So what is the logic behind this?

Once I had head someone mention that this distinction was made just to avoid adopting and following Component standards as laid down by Microsoft. Really there is no logic behind this.

Is this true?

Fixer

Please check this post: #763575 – Grijalva

Answer 1

A. Some components have large and complex design-time features such as property editors, which you may not want to include in your run-time application.

B. Some component vendors do not want to licence their large and complex design-time features for royalty-free run-time use, but restrict them to use by developers only.

Lading

Point A: What would happen if say for example DesignTime and RunTime packages get included in compiled EXE? I am asking this as now a days Memory is not a constrain any more as there is almost always ample memory available at any given time. I agree with point B to an extent but for a good programmer it will be small task to implement logic which will not allow loading of DesignTime interface during RunTime. This has always been case with COM components without any problems. – Fixer

Whether you use designtime units or not is resolved at compiled time, not at runtime. Packages are statically linked DLLs. Therefore using packages makes your target executable dependent on them, ie. Windows won't be able to load and run your executable if it doesn't find all dependencies. – Protrusile

I don't think so because if Packages are statically linked then where is the need for finding all dependencies? – Fixer

The need is in the way Windows loads and runs executables. Or maybe I don't understand your question. Packages are statically linked DLLs, whether you think so or not. ;-) – Protrusile

There's no such thing as a statically linked DLL, @TOndrej. DLLs are dynamically linked, by definition. (That's what the D stands for.) Package DCUs can be linked statically, but then they're included in the EXE, not separately. Package DLLs that the OS looks for when loading the EXE use what's known as load-time dynamic linking, as opposed to run-time dynamic linking, which is what happens when you call LoadPackage or, more generally, LoadLibrary. – Foot

One of the major component vendors that doesn't license design-time features is Embarcadero. That's why design-time packages are sometimes required. Component and property editors that use the DesignEditors unit can't be compiled without using Delphi's own design-time package, and that package isn't allowed to be distributed. – Foot

@Rob You are correct, I used a wrong term. When I said static linking I meant load-time dynamic linking.@Yogi sorry for my confusing choice of words. – Protrusile

@YogiYang007 RE: "now a days Memory is not a constrain any more"... I wish people would stop thinking like this - it's lazy and wasteful. You know how many keyboards nowdays have "special keys" for things like volume control, application quick keys etc. I've seen special drivers for such keyboards using > 4 MB memory. Why on earth would a special keyboard driver need that much memory?? -- It's because of lazy thinking. The large (never used) configuration GUI code is probably loaded along with the tiny bit of driver code that is used. – Electra

Answer 2

1. Designtime stuff may use Delphi's internal units/packages to which you neither have source code nor are legally allowed to distribute in binary form.
2. You probably don't want to make your application require Delphi to be installed on the user's computer.

The logic is to keep your own code separate from the "glue" code which makes it nice & easy to work with in the IDE.

Protrusile

Say for example if I as a VCL writer of a Grid control, I want to give facility to my users to make changes to a Grid layout, etc. at run time as they would be able to do at design time then I can do this? After all I have to use standard controls provided by CG and build on them, or have I to create the UI from scratch on my own? – Fixer

Yes you can do this. Designtime refers to libraries used by the Delphi IDE. That includes property editors, code creation wizards, in short any code which interacts with the IDE. For example, TStrings editor which you can use in the IDE to edit TListBox's Items property is designtime. TListBox itself is not. If you want to provide a similar editor to your users to let them edit the items at runtime you have to provide your own. – Protrusile

Answer 3

If you had done a little bit of research, you'd have found this SO question asked less than 2 days ago...

As already explained the main reason is that you cannot include any Delphi Design unit in a runtime package. And there is no reason to bloat your executable with code that can only run within the IDE anyway.

Kei

THis should be the accepted answer, except for the snark. :-) – Pick

Answer 4

The short answer is... If you want to do it properly, it's complicated AND comes with a drawback.

The not so short answer is... use lazy man's solution: the runtime/design time mix. Also comes with a possible (but unlikely) drawback.

---

The full answer is:

Whatever library we install, it comes in two “flavors”: runtime libraries and design time libraries (actually, there are three… keep reading).

Run-time libraries

Some libraries only provide run-time routines and no visual components (VCL).

1. We just compile this library. There is nothing to “install” (there is no “Install” entry into the pop-up menu for such library).
2. Include library’s files into your project (drag and drop it into the Project Manager) or add the library’s path to the “Search Path” / “Library Path” as shown above. Now, we can simply call the functions of that library from our program.

If the library has two packages (two DPK files), one marked as Design time and one marked as Runtime, always compile the Runtime library before the Design time library. Note that sometimes there is just a “D” (Design time) and an “R” (Runtime) at the end of the name. If we start with the Design time library, it may complain that it cannot find the Runtime library.

Design time libraries

Libraries that provide visual components are design-time libraries*. We need to load these libraries in Delphi (into the Project Manager) and install them.

After the installation, the visual components of that library will appear into the “Palette” so we can drag and drop them on our form, at design time. The documentation of the library will tell us under which category we will find the new installed components. If there is no documentation, do a search into the units of that library for a procedure called “Register”. This will take as parameter two strings: the name of the component and the category where it will appear in the “Palette”:

The TRichLog component will appear under the “Cubic” category in the Palette.

If we don’t want the library anymore, we right-click on it in “Project manager” and choose “Uninstall”.

Design time and Run time libraries

Some people might not agree with my statements above. See these pages for details: RobsTechcorner.blogspot.com/2011/06/runtimedesigntime-what-delphi-packages.html

This is because, in theory, design time packages should only contain code for special things like property editors (you can see property editors in the Object Inspector). And the runtime packages should only contain code that is not necessary during development. Runtime packages should never contain or require design time code. This is the theory. The good way to program and keep your code separated. However, this comes at a price: it could be difficult to keep these two separated.

The solution is to declare your packages as mixed “Design time and Run time libraries”.

By the way, when using the wizard to create a new package, Delphi will declare that package as “design time and runtime” by default. But still, this is considered, lazy man’s solution. To be honest, I only use this solution. Even though I created lots of visual components, none has design time editors.

Grijalva