Dproj changed or not changed? Normalize it!

I guess it is since Delphi 10 Seattle that dproj files are changed on disk even if no change was done to the project settings inside the IDE. This is a real PITA with version control systems.

Actually there are no changes to the content – it is just reordered somewhat randomly. The only consistency is that the order changes with every save operation. The reason seems to be the use of dictionaries for some entries inside the IDE.

As this bothered me a lot recently I wrote an IDE plugin that orders the dproj file in a consistent way. It is called DprojNormalizer and can be downloaded here:  DprojNormalizer

DprojNormalizer has no settings or options. It does its job while it is installed and active. If you don’t want that you have to disable or uninstall it.

If you find cases where the dproj file unexpectedly changes, please give me a note and I will see if it can be handled as well.

Conditionally using FastMM avoiding IFDEFs in the DPR

This a follow up of my previous post Conditional Uses Clause Considered Harmful, showing another real world use case of the technique described there.

Let’s assume we want to use FastMM with Full Debug Mode in a project to track down some errors in DEBUG mode. This requires us to include the FastMM4 unit as the first entry in the uses clause of the project DPR.

Now let’s also assume, we don’t want to use that FastMM unit in the RELEASE configuration – and – NO! – we don’t want to use an IFDEF inside the DPR, as the IDE tends to mess up with such things pretty often.

Using a unit alias like

  • FastMM4=System

solves this in a simple and elegant way.

 

Conditional Uses Clause Considered Harmful

Everyone writing Delphi code that is meant to compile under different Delphi versions has come to the point where conditional compilation seems unavoidable. Ever so often it tends to creep into the uses clauses as well. So, what can we do when units like System.Actions and System.ImageList simple aren’t available in older Delphi versions?

Solution 1: Add an empty unit with the proper name to the project. You might end up with a collection of empty units in your version control system. But hey, it does the job.

Solution 2: Add a unit alias to the project, mapping the unknown units to existing ones you are using anyway. For the two units mentioned above some good candidates are:

  • System.Actions=Vcl.ActnList (for versions below XE3)
  • System.ImageList=Vcl.ImgList (for versions below XE8)

There are a couple of tools that fiddle around with your uses clause from time to time. They will thank you for getting rid of conditions there.

Package Magician v1.0.4 and Selective Debugging v1.0.4

Package Magician has got some small fixes in version 1.04:

  • Fix: Closing a project and opening another one doesn’t trigger the active project change event and thus wasn’t recognized, leaving the loaded packages in an unwanted state.
  • Fix: Editing the settings wrote the resolved default path into the settings file.
  • Fix: Setup always showed Delphi 10.1 Berlin enabled, even if it was not installed at all.
  • Fix: Setup now makes the registry settings for All Users, too.
  • Feature: Workaround for RSP-15285

As Package Magician shares the setup with Selective Debugging (despite the app name and app id obviously), those two fixes in the setup are also reflected in Selective Debugging version 1.0.3:

  • Fix: Setup always showed Delphi 10.1 Berlin enabled, even if it was not installed at all.
  • Fix: Setup now makes the registry settings for All Users, too.
  • Feature: Splash screen and About box entry added.

You can find the new versions in the download section.

Update: The Selective Debugging icon didn’t make it into the versions for XE to Seattle. Fixed in version 1.0.4. Nothing else changed.

Package Magician and Search Paths

Some people using Package Magician or evaluating it asked me to add some sort of search path handling. The usual scenario is that a library installed into the IDE via its setup also adjusts the global library path pointing to the necessary DCU files. Some libraries consist of quite a bunch of packages to be installed into the IDE and thus are not easy to be installed manually, so using the setup is a reasonable option.

Now assume f.i. you have access to the beta version of that library and want to test it with some of your projects, but you still need the release version for your production environment. Let’s further assume you have set up Package Magician to handle the loading and unloading of the respective packages depending on the current project. The problem now lies in the global library path still pointing to either the release DCUs of this library or the beta ones. Continue reading “Package Magician and Search Paths”