The Art of Delphi Programming

There is a new version V2.1.0 for DprojNormalizer available, which targets a problem when using option sets and/or build events. Thanks to Peter Sonderegger for bringing this to my attention.

Be aware that this version may change the sorting of your dproj files triggering a version control change. Well, it obviously does that – otherwise, what would it be good for?

The new version can be downloaded here:  DprojNormalizer

I just added support for Delphi XE2 to XE6 in DprojSplitter V1.0.4 – no change in functionality so far.

As I currently don’t have the time to test the plugin in all supported Delphi versions, please give me a note if anything is not working as expected and I will fix it as soon as possible.

In case you are still using a Delphi version below XE2 you have to be patient. The relevant dproj settings are stored in a different way in older Delphi versions, so supporting those is not just a matter of making it compile, but implementing it in another way.

To justify the effort I would like to hear from you which Delphi versions you would like to see supported, so please drop a short comment here.

Some of you are probably already using my DprojNormalizer plugin for Delphi, which tries to reduce the unwanted differences disturbing your version control system. It does this by forcing a dedicated order of the entries found in the dproj file.

Unfortunately it doesn’t help for those cases where you make changes to the project configuration but don’t want to spread these changes into the version control. For example, changing from Release to Debug configuration or switching to another target platform are some of these changes, but usually all the settings found under the Run – Parameters menu belong into this category. These settings often reference folders or files local to your machine or are in some way not suited for your colleagues systems.

So let me introduce DprojNormalizers little brother: DprojSplitter!

DprojSplitter takes care of these settings mentioned above and stores any changes you made to them in a separate local file with a dproj.user extension (sorry, dproj.local was already occupied). The corresponding settings in the plain dproj will be reverted to the state when it was loaded. When opening a project, DprojSplitter looks for such a dproj.user file and, if found, merges it into the project settings found in the plain dproj file.

This way you can have your local settings private to your system and so can your teammates.

DprojSplitter is similar to DprojNormalizer: if it is loaded it does its thing. If you don’t want that you have to remove it from the installed packages. This might be necessary when you have to make some changes that actually shall go into the version control this time.

You can download DprojSplitter here:  DprojSplitter

As always: if you find any error or problem, please tell me.

Recently Embarcadero closed the QualityCentral website and actually Jim McKeeth blogged about that.

Just in case you want to download the content of QualityCentral, I slapped together some code to achieve that: QCScraper

You have to insert your EDN email and password and specify a target file name. Note that the download can take a couple of hours to finish. The resulting file can directly be loaded into a TClientDataSet, so you have plenty of options to work with it and store it to your needs.

Currently the attachments of each case are missing and the lookups are not resolved, but the provided code should give you enough hints to implement that by yourself.

Be aware that the cases returned are specific to your account and may contain records not seen publicly. That is one reason why I don’t provide the downloaded file directly.

BTW, the code is only tested with Delphi 10.2 Tokyo.

In the comments of the last blog post about encrypted zip files several people encountered problems with zip files encrypted with the shown sources. Well, I have to apologize: this actually cannot work with the sources provided due to some suboptimal behavior of TZipFile. Its current implementation calculates the CRC32 value after encrypting the data. For that the CRC32 value used for encryption is simply incorrect.

The reason why this slipped through is damn simple: As my first approach was implementing this feature in the original sources, I changed this right in the beginning and later forgot about it completely when moving this feature into a derived class. Thus my tests succeeded just because they still used the manipulated version of System.Zip.

It turned out that getting the correct CRC32 value for encryption without changing the original source was anything but easy. For the sake of providing at least one solution in a timely manner, I opted for sacrificing performance and memory considerations, which can surely be optimized in a later approach. As a benefit the current solution also closes a memory leak present in the previous version.

The new version can be downloaded here:  EncryptedZipFile