Custom components - how to manage?

I've made a couple of programs which I release as freeware on my webpage. One of these programs uses TSpinEdit for some number input. It works quite well, so I haven't really had any reason to use anything else.

However, yesterday, a user told me he didn't like how small the buttons were. I can't really disagree, because, well, they are. Unfortunately, the only way to make the buttons bigger is to make the control bigger, and that really doesn't look nice. Instead, I decided to change the component a bit so the buttons were placed next to each other, instead of on top of each other.

Now, Delphi won't let me include this new component directly in the DFM, because it's currently not installed - it's just a file that's added to the project. Obviously, it would be nice to change this - not just because it'll let me keep the controls in the DFM, but also because it lets me reuse the changed component more easily - so I'll have to make a package and add it to there. That's fine, I can do that.

But that brings me to my question: How should I manage this package?

Are there any problems in adding any other co开发者_运维问答mponents I make to the same package, or would it be better for me to make multiple packages and divide them into logical groups?

I use version control, of course, so propagating changes to component code between my desktop and my laptop isn't a problem - but will I need to rebuild the packages manually on each workstation every time I make a change, or is there a trick I should be using?

I have a few "my" components which are grouped in single package. In package options set "rebuild as needed". I believe it does a trick, at least in my case (I'm developing the application both on my home PC and my notebook, using SVN) - it recompiles the package during project compilation, but it is runtime one (shared package; for app and it's plugins). I'm not sure how about designtime, I'm afraid you'll have to reinstall them manually each time you change something ...

Or, if using the same delphi versio, why don't you put binary files (.bpl, .dcp) in the shared (versioned) folder?

How should I manage this package?

You can add any component to your package, and installing the package installs all those custom components into Delphi IDE.

A package could be runtime, design-time, or both. A runtime package has no IDE interaction and will not install in the IDE. Runtime packages provide routines and classes used by other packages at runtime. Design-time packages are packages that have interaction with IDE.

Usually you use designtime-only packages for installing IDE experts, or property editors. Actually anything that just interacts with IDE, and has nothing to do with the compiled file.

Packages that are both runtime and designtime are the ones you usually add your components, and install them into IDE. Such packages interact with IDE, but are also compiled into the produced file too.

So if have some supporting routines and classes that are going to be used by a group of your components, you can put them in a runtime package, and use that package as required package for other packages.

If you have some code that customizes IDE, or adds some features to IDE, put them in a designtime-only package.

If you have components which are going to be used in your compiled applications, then you can put them in a runtime and designtime packages.

I use version control, of course, so propagating changes to component code between my desktop and my laptop isn't a problem - but will I need to rebuild the packages manually on each workstation every time I make a change, or is there a trick I should be using?

If you use the same version of Delphi in both your laptop and PC, then after changing the source code, you have to rebuild the package at least once to create the compiled BPL file for your package. Once the BPL file is compiled, you can copy it to the other machine (to the folder in which you store BPL files. By default in Delphi 2010, it is C:\Users\Public\Documents\RAD Studio\7.0\Bpl), copy DCU files to that machine, and run Delphi IDE on that machine. Delphi IDE will automatically load the newly built BPL file for you. So in brief, if all your machines use the same version of Delphi compiler, then you can compile your package once, and use the compiled package in other machines without rebuilding the package.

We have a number of different apps that are built with slightly different component sets.

We create a project group that includes the main application and all components (apart from standard Delphi ones) that the app uses. We have a folder underneath the application folder for storing source for all the components. The component folders are generally shared within the source control system to avoid duplication, but can be branched if necessary.

We always create shortcuts to start Delphi configured for the particular app we are working on (using the -r command-line flag).

All this means that we can create a release branch that includes the components at the time of release, and we can have multiple instances of Delphi running, each configured to use the correct components for the version of the app being worked on.

If you take this approach though, you must create separate BPL/DCP output directories for each instance of Delphi, and make sure you remove the default BPL directory from the search path.

One package cs Multiple packages: It boils down to how you distribute your software. Having multiple packages for multiple components allows you finer control over what you need to distribute (in the form of o source code or runtime packages). Having a single bigger package wold be easier for you as a developer: only one big package to rebuild whenever you make changes.

For my components I elected to use multiple packages; I now regret my decision but it's too late to change. When I need to set up a new workstation I need to figure out what packages need to be included and in which order they need to be compiled. If I only used one big package I'd simply take the package out of Version Control (I'm using JEDI) and BUILD, that's it. The big package would work for me just fine because I don't distribute source files and I don't distribute runtime packages.