Fuss over Runtime and Design Time packages in Delphi

views:

546

answers:

+2 Q:

Fuss over Runtime and Design Time packages in Delphi

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?

+10 A:

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.

frogb 2009-04-20 11:05:48

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.

Yogi Yang 007 2009-04-20 11:16:37

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.

TOndrej 2009-04-20 11:25:43

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

Yogi Yang 007 2009-04-20 11:27:45

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. ;-)

TOndrej 2009-04-20 11:33:22

+4 A:

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.
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.

TOndrej 2009-04-20 11:18:09

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?

Yogi Yang 007 2009-04-20 12:48:46

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.

TOndrej 2009-04-20 14:03:58

+2 A:

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.

François 2009-04-20 17:18:29

ansaurus

tags:

views:

answers:

Fuss over Runtime and Design Time packages in Delphi

related questions