Uwe Raabe

Unfortunately, changing any version information values at least once will break inheritance and the values in that build configuration have their own life. There is no built-in way to establish inheritance - unless the entries are removed from the dproj with some exterenal tool. That is the reason why Project Magician has this option

Can you elaborate on what do you expect instead?

And they are back again!

Not sure about your system, but when I here hover over your post there is a Report post label highlighted in the post title to the right, which can be used to, well, report the post.

Existing project is just a bit vague.

I would also recommend doing it in one step to the most recent version. Just make sure to disable all new features like VCL Styles or High DPI support (which is enabled by default). Using the IDE in highdpi:unaware mode may also simplify ones life in case one has a high dpi system for development.

I luckily managed to grab a copy in good condition (including CD) for unbelievable 12.38€ - sometimes it pays to have relatives in the U.S. Now I only have to wait for them visiting us in November, but looking at the ~65€ they tried to charge for shipping it to Germany that is definitely the better option.

That is not limited to frames, but affects forms and data modules, too. Looking for external links is done by component names - thus the first found wins. One could argue that this could be extended by inspecting the unit names available in the uses clause, but it is just the other way round: When the (wrong) component is found by name, the (wrong) unit name is automatically inserted when it is not available in the uses clause already. The designer part of the IDE is a mighty and sophisticated invention, but it has its limitations. What can be done is not nearly the same as what should be done.

Looks like as designed:

They are hard-coded.

At least recent versions of Delphi allow adding repositories located at arbitrary places. So if various computers have access to a common network share, you can use that for your templates. Alternatively one can manage these repositories and its templates with version control as with any other sources like f.i. common library code.

Alternatively create a new project and save it (best with decent file names). Then select Project - Add To Repository from the menu, select a proper place to add and type some nice names. After that you can select File - New - Customize to add the new entry to the favorites. As a gimmick you are directly asked for a target folder after selecting your project from the repository. Also, when all your VCL projects have a main TForm and a main TDatamodule and a separate TDatamodule with a TImageCollection, you can prepare that before adding the project to the repository (or create a separate entry for that) and you may save quite some more clicks and keystrokes.

Interesting. Just recently someone in the German forum claimed that as a welcomed feature here.

In 10.3 there is just no ImageName property in TToolButton either. ImageName support started with 10.4. In 11.3 there still is function TVirtualImageList.IsImageNameAvailable: Boolean;

In 10.4+ it is and versions before have no ImageName properties. function TVirtualImageList.IsImageNameAvailable: Boolean; begin Result := FImageNameAvailable; end; Actually that function is introduced in TCustomImageList. It is just overridden in TVirtualImageList.

You can as well override the IsImageNameAvailable function for that subclass and just return False.

The ImageName can only be stored when the linked image list supports it. A plain old TImageList does not, so that won't make any problems. The new TVirtualImageList introduces ImageName support, but makes it configurable with its ImageNameAvailable property. Setting that to False avoids setting the ImageName property on the linking controls. You might have to clear existing ImageName values manually, though.

... and the ability to simply move the database file from embedded to server and vice versa.

It is also much easier to switch from Embedded to Server when necessary. With SQLite you are nailed to embedded.

This usually happens with embedded drivers that require exclusive access to the database. This would even happen when you run your project, open the IDE and try to set Connected to True. Also when you run two instances of your program at once. I doubt there is any automatic solution covering all these cases. It should not happen with a decent InterBase or FireBird server, which are able to cope with multiple connections at once. Perhaps using one of those during development helps to circumvent the problem.

Nevertheless are there several cycles as shown by MMX Unit Dependency Analyzer: Here is a part of the Dependency Graph from Understand for the VirtualTrees -> VirtualTrees.WorkerThread cycle with information where the dependencies come from in the Dependency Browser below:

Yes, it does: Supported Languages. They are also providing new releases in a reasonable time frame. When I provide a test case showing some syntax confusing the parser, they usually fix it in the next two releases. OK, but that doesn't say anything about the quality and usability of the product. I may have reacted the same when I had found the website myself, but I already had another product from their German reseller, when they contacted me with a trial of Understand. That was 2014 and I declined with a comment about the poor Delphi support. In 2016 they came up with that again, and I agreed, because the Delphi support was sufficient for me at that time. Meanwhile, with some significant help from myself, it became even better. As I often have to cope with foreign code and for that it proved very helpful. It turned out that it also gives some valuable insights in my own code, especially the sort of code that evolved over time. I am glad to have this tool at hand. One can argue about their sales channel, but IMHO that doesn't diminish the product itself. BTW, one can always try to negotiate with the reseller.

Just a small anecdote: Working on one of my customers code base, which is heavily convoluted with circular references, I was able to break a cycle with simply using a string literal instead of a global constant declared in one of the units, knowingly sacrificing at least some of the Clean Code principles. The constant was declared like this: const cLocalHost = 'localhost'; BTW, a valuable tool for me to understand someone else's code and detect the fibers a cycle is made from is SciTools Understand. Although it may look a bit expensive for some at first, the time saving effects are absolutely worth it.

Relying on unit scope names also makes the compiling slower. Besides MMX there is also UsesCleaner as its command line companion resolving these issues.

Avoiding circular unit references speeds up compilation significantly. Let me cite @Bill Meyer in his excellent book Delphi Legacy Projects : Strategies and Survival Guide: As slower compile times also affect the IDE, especially Code Insight, we are not just talking about longer build times, but responsiveness of the IDE itself. Also mentioned in the book and backed by my own experience and involvement, a very helpful tool is the Unit Dependency Analyzer built in MMX Code Explorer (also available as standalone). Bill dedicates a whole chapter in his book on Cleaning Uses Clauses.