There Can Only Be One – At a Time!

Handling Different Versions of Design Packages inside the IDE – Reloaded

This is a follow up of my previous post There Can Only Be One! where I describe the problems encountered when different projects need different packages or versions of loaded into the IDE during design time. In that post I came to the conclusion that the IDE is currently not able to handle this. So I decided to invest some time and wrote a plug in to address this issue. So, Ladies and Gentlemen, we proudly present: Package Magician.

If you have read my post mentioned above – you did read it, didn’t you? – What? You didn’t? OK, so go and read it now. I’ll wait here… – yes, I’ll wait… – I promise!

Fine, there you are again. Now, after you have read that article, you should know about the problem and how I suggested to tackle it. The implementation of Package Magician follows the described behavior, although with a slight derivation: Required packages are still loaded when a project is loaded (everything else would be nonsense), but when the project changes all of these previously required packages are unloaded unless they are also required from the new project. This reduces the number of packages to be listed as forbidden – in most cases to an empty list.

Package Magician installs as a normal design package listed under the Known Packages registry key and can be loaded or unloaded in the Install Packages dialog as usual. When loaded, it adds a menu item inside the project menu next to the Project Options (Other packages also placing a menu item next to Project Options that happen to be loaded after Package Magician may steal that nearest place and push Package Magician further away from Project Options – naughty, indeed!). Executing that menu item will open this configuration dialog:

Screenshot Package Magician

Initially it is empty, which results in the IDE behaving as if Package Magician were not even installed at all. The magic happens when you fill the Required list. Enter the full path to the appropriate BPL file you require for your project. The package may already be loaded inside the IDE – it probably will as the project actually requires it.

You can use IDE macros like $(BDSCOMMONDIR) provided by the IDE to make your entries Delphi version agnostic. Package Magician handles two additional macros: $(PROJECTDIR) and $(LIBSUFFIX). The first one (you guessed it) resolves to the path where the project file lives, while the second one is replaced by the LIBSUFFIX of the Package Magician BPL (which itself adheres to the Delphi package numbering scheme). You can declare a LIBSUFFIX macro inside the IDE which takes precedence.

If you give a relative path for the BPL it will be prefixed with the value from Default path, which itself defaults to $(PROJECTDIR) if empty as indicated by the grayed text hint. Be aware that the entry in Default path has to be absolute! To specify a subfolder of the project folder use $(PROJECTDIR)\<some sub folder>.

As Package Magician will unload all no more Required packages when the project changes (that are all packages required by the previous project but not required by the new one), there should rarely be a need to fill the Forbidden list. It might actually be useful when there is a chance that any package could be installed into the IDE permanently and thus has to be removed before the project loads and tries to install its Required packages that interfere with those. To ease this task a bit the entries in Forbidden allow for wildcards.

Now every time you open that project all the packages listed under Required will be loaded and your forms should open without any errors and without silently upgrading to newer component versions. When you open another project all of these packages not required by the new project will be unloaded.

That does even work inside the same project group. Caution! This needs some attention. When a form is open containing a component from a package to be unloaded, the form is closed and the IDE switches to the source code. That’s all fine if you leave it so. Don’t try to open that form again while the required package is unloaded. That will place you into the same situation as you were without Package Magician: the IDE either cannot find the component and offers to remove those from the form (splendid idea) or the wrong version of the component is found and some properties may be changed, removed or added – perhaps even silently. So be careful!

Oh, yes – the download:  PackageMagicianSetup

And here are some test cases as an example:  PackageMagicianTestCases

Update: The setup actually registered the Seattle package into Berlin. Fixed with V1.0.2.

Author: Uwe Raabe

Addicted to Pascal/Delphi since the late 70's

3 thoughts on “There Can Only Be One – At a Time!”

  1. Hi Uwe,

    I really need this package but D10.1 complains that can’t load the specific package (the specific module could not be found) although the file exists in the location.

    Any ideas what may cause this?


    1. Sorry about that! There is an error in the setup which registers the Seattle package in Berlin. Simply remove that package and install the correct one manually. I will fix the setup ASAP.

Comments are closed.