When to Install, vs. when to just build, visual component packages that are part of a larger project

Question

Context:

I have been working on and off on an application which uses a number of custom frames-based components (which folks around here have been super helpful with as I've been learning!).

Since I am modifying the visual component that the app uses very often, and those components are fairly numerous and interrelated (quite a bit of inheritance going on, etc), I'd like to streamline the modify/build process as much as possible.

Question:

When is it necessary to actually install a visual component package, vs. just building (or only "compiling"?) the EXE project which uses and references those components? Do I only need to truly "re-install" a package to the palette when I change a member that would be affect the Object Inspector? Any conceptual guidance here would most welcome.

Thanks again, in advance. : )

Answer 1

The IDE normally detects when you're recompiling a package that the IDE has loaded. When you compile the package, the IDE will unload the relevant design-time packages first, and then it will attempt to re-load them when compilation finishes.

You should be making changes to your package while that package is selected as the active project in the IDE. (You can use "project groups" to let you have multiple projects open at once. Only one at a time can be the "active" project.)

That's as opposed to having your package units compiled implicitly when you compile your application. My advice is to avoid that scenario. It lets your packages and your project get out of sync much more easily, partly because the package won't be loaded in the IDE, and partly because you'll be more apt to make project-specific changes to the package units instead of pausing to consider whether the change is really appropriate for the shared package. The moment it takes to switch the active project can be enough to keep the package and the application separate in your mind.