views:

102

answers:

1

After reading some mailing lists and bbs, I couldn't find a proper way to setup my development environment for package and component development. Perhaps we can collect some tipps here for a good setup.

For component development it is suggested to create a runtime package containing the runtime code for the component and a design time package which uses the runtime package and only registers the components for the delphi ide.

So in my case I use a group project which contains the following projects:

MyComponentGrp
|
+- MyComponent140.bpl      //the runtime package containing TMyComponent
|
+- DclMyComponent140.bpl   //designtime package wich registers TMyComponent
|
+- TestApp.exe             //an application to test the component

This setup works fine, but changing some code in the runtime package requires to reinstall the designtime package, to have the changes applied. I do understand that behaviour when I have to add new properties. But when changing code inside a method for example, it should suffice to generate the runtime package, shouldn't it?

How do you setup your IDE for component development?

+2  A: 

I don't find it hard to hit the "build all" menu item, to build my entire project group, however, for more reasons than the above "build two packages" reason, I find it useful to have different stages in component development, where I "use" the component differently, and handle development differently. You do not have to reinstall, only rebuild, each time. Install adds a line to the registry and causes the BPL to be loaded into the IDE. If it is rebuilt, it is reloaded too.

  1. in early prototyping and functional development of a component, I am focused on testing the component's runtime behaviour, and I don't even need to have it on the palette yet. I use unit tests, and test harness forms, and code which creates the component IN CODE instead of at design time. this avoids the need to be constantly rebuilding and reinstalling TWO packages.

  2. I might be tempted to avoid using two packages and use only one package, which contains the MyCompRegs.pas file, which contains ONLY the register components code, during early development.

  3. When I am nearing a final build of my component I would be sure to package it properly, and provide both designtime and runtime packages. If I start actually writing any designtime code, other than the RegisterComponent one-liner, then I might start the designtime package sooner.

  4. During maintenance, and ongoing technical support and fixes for the component set, I would leave the package arrangement separated as you have it.

Footnote: The design package often contains nothing but a one line call to register a component on the palette. Nevertheless, in general, Designtime coding is an important part of what makes some of the best Delphi components powerful, but not all components have designtime code, some might be very little designtime code at all. the reason for the distinct packages in Delphi (separating the designtime from the runtime code) became a requirement at some point in Delphi's history (around Delphi 2006, I think), to prevent Delphi's designtime code from being linked and distributed inside runtime packages.

Warren P