Uwe Raabe

You might have better luck with TPngImage.CreateBlank.

Probably related: https://quality.embarcadero.com/browse/RSP-43125

Of course it is possible to write the SVN revision number into the source, but when you commit that change to SVN it gets a new revision number. That's why SVN replaces a special keyword in the sources with the current revision number. Letting alone that the concept of a revision number is some SVN thing and has no counterpart in most of the other version control systems for several reasons. The more I think about it the more I like the no-downloads approach...

While "of all" can also mean "of all open". Given that Bookmarks stores its bookmarks per file it may not have any concept of "files of a project", while "open files" seems like a valid filter. Otherwise it would resurrect this question:

C'mon, that is just not true! The help is available here: https://docwiki.embarcadero.com/Libraries/Athens/en/Vcl.FileCtrl.SelectDirectory

If you just registered for the portal it needs some time to get you attached to the proper group. To speed that up you can file a new issue yourself.

This can happen when the Patch has been installed with another user or different registry branch.

The Bookmarks plugin already provides a list of bookmarks for all open files. There is also an option to give a name to each bookmark. Looks like the only missing feature is to show the bookmarks from all project files.

I wonder if that can be implemented based on the Parnassus Bookmarks plugin available in GetIt. The API description mentions:

As I am not familiar with this feature, I wonder what the difference is between a standard bookmark and a global bookmark.

Well, it is definitely not a bug, so in case you filed it as a bug the "Works as expected" is indeed a valid answer. A dimmed selection color is actually standard behavior for non-focused Windows controls. Better file it as a feature request, as it asks for a change of the current, technically correct behavior.

Before doing so, the developer needs to get assigned a task for it. This requires the product management to schedule such a task, which itself requires that there actually exists a request for it. If there isn't already one in the issue tracker I suggest to create one.

I am not sure if that actually is a native Windows control. Given the context aware, mixed font style and color node drawing it could as well be a TVirtualTreeView descendant.

To reduce the need to keep that file updated with every new Delphi version I just changed that phrase into a version agnostic alternative. Will be available with the next update.

Probably lack of time to update the less important parts.

These dialogs are not part of your application, but are provided by the operating system and thus follow the Windows settings. There is not much you can do about it. The app BDSSetLang.exe found in teh Delphi bin folder has an option to change the Library language apart from the IDE language. This will use another set of resources when compiling your application.

I wonder if 42 would do, too...

Showing the actual content of the DBW.ini file located in E:\DBiWorkflow. Best attach the complete file so we can scan for suspicious characters.

Usually, yes! Peganza Pascal Analyzer even has a report for that:

You can as well simply scroll the form as needed, but the need to scroll was exactly the complaint.

Indeed, but they still reside in the interface section and thus may need some units being used in the interface section instead of the implementation section.

Another option could be calling SetLocaleOverride with the desired value. It just has to be done quite early as long as no resources are being loaded.

You can add a registry entry under HKEY_CURRENT_USER\SOFTWARE\Embarcadero\Locales for that. Of course that only works at application start, so no change at runtime possible. One tool supporting changing languages at runtime is Korzh Localizer.

IMHO, having local procedures/functions using outer-scope local variables is often a hint for having a separate class for this functionality. I wish we were able to declare something like a local class type inside a method, just as we can declare a simple record type. In the moment I work around that limitation by nested classes unless I want it hidden from the interface, which forces me to make it a regular private class.

Scaling forms is always problematic. We can see this every day with applications (not only Delphi ones) when used in a mixed DPI environment. Although I don't actually suggest to use it, there is an option to switch the form designer using a special PPI. The drawback is that it is used for all forms and not only for the large ones. Naively thinking that scaling the form display could easily be done by drawing onto a bitmap and simply display that downscaled, but that would imply that the whole user interaction has to be made with a bitmap instead of real controls. The effort to implement that with all its edge cases is way more than one would expect.