Uwe Raabe

That will also save memory when multiple instances of the frame are created.

The REST packages depend on the LiveBinding packages. I cannot say why it happens out of a sudden, but even when the LiveBindings Design packages are disabled, the Runtime packages should still be found.

That can also mean a package required by the named ones and which cannot be found or cannot be loaded for whatever reason.

Seems to be some roadblock there: I would try to remove that roadblock first. There will be other paths being blocked by it which are just not visible yet.

Yes, is was MS itself making that error. BTW, Windows 10 requires a reboot for the changes to get applied - and there is a similar entry under the WOW6432Node (both should match). Anyway, there were several things done to fix a GDI leak and significantly reduce the overall GDI handle usage in Delphi 11.

What is your registry value for HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows\GDIProcessHandleQuota? Could it be that it is 10000 decimal instead of 10000 hex? See more here: https://docs.microsoft.com/en-us/windows/win32/sysinfo/gdi-objects

That is not the Authentication tab.

Can you show the Authentication tab, please?

Details from Marco: https://blogs.embarcadero.com/rad-studio-11-alexandria-patch-1-available/

That would only qualify as a LTNS version

OT: I was very pleased to see GitHub recently offering Colorblind Themes for people like me, who have difficulties to distinguish between red and green. (Actually I am able to distinguish both colors, but they look almost the same and I cannot say which one is green and which is red)

If you manage to load the old TPngObject instances hidden in Picture.Data, you can export those as PNG files and load them again. This way they should end up as TPngImage. Not sure what XRE means, but TPngImage exists in Delphi since Delphi 2009.

Well, I can. The problem is that TPngObject is declared as an alias for TPngImage in Vcl.Imaging.PngImage.pas. Unfortunately an alias cannot be registered as an alternative type, because internally it is the same type. PngFunctions.pas declares its own TPngObject as descendant from TPngImage, but these two TPngObject are not the same types. These both types don't play well together somehow. To get things straight please remove the RegisterOldPngFormat define and compile the PngComponent packages again. Then open all your DFMs in a text editor (convert them first in case they are still binary) and replace all TPNGObject references with TPngImage.

OK, that's definitely not intended. The shortcut should only trigger when UDA is focused. I will see what goes wrong there.

uses System.StrUtils; var S: string; begin if Memo.Text = '' then raise Exception.Create('no SQL found'); S := SplitString(Memo.Text, ' ')[0]; case IndexText(S, ['SELECT', 'INSERT', 'UPDATE', 'DELETE', 'CREATE', 'ALTER']) of 0: MyQuery.OPEN; 1, 2, 3, 4, 5: MyQuery.EXECSQL; else raise Exception.Create('unhandled SQL command'); end; end;

The Left and Top properties of the components on the datamodule as well as its Width and Height are stored in the DFM. When you design a datamodule on a system with 200% scaling and open that later on a system with 100% scaling the datamodule would be shown twice as large. The other way round, when you design a datamodule with 100% (like all datamodules created in previous Delphi versions) and open that on a 200% system, most of the components and their names would probably overlap, because the icons and fonts are scaled in the designer (otherwise they were way too small). When Delphi 11 opens one of those old datmodule it correctly assumes that it was designed with 100% and scales it to 200%. When saving would omit to store the used PixelsPerInch value in the DFM the (already scaled) datamodule would be treated as designed in 100% according to the scheme described and scaled again. Don't get me wrong: I think this is the wrong approach. Scaling for designing is good, but when saving it should be forced to downscale to 96 PPI again. That way the additional PixelsPerInch property in the DFM can be removed. I also suggest to adopt this behavior for forms and frames accordingly.

If you actually use that code literally, where is the type TPNGObject declared? It is not available in Delphi nor is it in PngComponents (at least not public).

I didn't see that here.

I can understand that you want to get the old TPngObject images read from the DFM, but why do you want to work with the TPngObject class? After all it is declared in the implementation part of PngFunctions.pas. Can you show which declaration of TPngObject is used in the code snippet shown?

Sounds to me like chasing the wrong rabbit.

In that case these bugs didn't you bother either before. A net gain for all of us.

That is basically what you already can achieve with Delphi when you work with dynamic package loading. The point with such an approach is that the code must be able to store and restore states between a reload.

They are visual in the designer and the designer has to know the resolution the datamodule has been designed last. I know this is annoying and even error prone. That's why I made a suggestion to store all dfm with an implicite PixelsPerInch value of 96 and scale only for designing: Option to design in Screen PPI but save in 96 PPI That may cause the non-visual components on the datamodule moving out of sight in the designer when the datamodule is opened about 2-3 times.

The current debugger lets you simply drag the execution pointer to a line before or after the current position:

That raises the question: How much of the subscription price is declared being used for patching older versions? (and can I exclude that from my subscription when I don't need that?)