Uwe Raabe

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?)

I suspect smart loading is tripping in here. The registration of TPngObject is done when the TPngComponents package is loaded. As TPngComponents is a runtime package, is it loaded when the design time package PngComponentsDesign is loaded. The smart loading feature of the IDE loads design time packages when a component registered by that package is needed, be it by opening a form containing such a component or by dropping such a component onto a form. You can try to fix that by yourself: Open PngComponentsRegister.pas and add the line ForceDemandLoadState(dlDisable); at the beginning of the Register procedure. Then compile and install the design time package again. procedure Register; begin ForceDemandLoadState(dlDisable); //Register all components RegisterComponents(SPageName, [TPngSpeedButton, TPngBitBtn, TPngImageList, TPngImageCollection, TPngCheckListBox]); //Register component editors

Looks all pretty decent to me. I'm out of ideas what can be the cause of these problems.

Probably there are reasons...

The 32-Bit design package also needs the 32-Bit runtime package. The 64-Bit runtime package is only needed if you build a 64-Bit exe and build it with packages.

Well, that may indeed be problematic. The fact that I have a 16 core machine may hide that here. I will think of something to make the multi-threading optional, but there always has to be at least one thread besides the main one.

Not quite. If you declare your program as Per Monitor V2 aware you have to implement it this way. Otherwise things will probably look a bit ugly. Most of these events are handled by the VCL, but you should expect a few remaining problems - just be prepared.

I cannot reproduce here, neither in Delphi 11 nor in Delphi 10.4.2. The only difference is that I installed both plugins the other way round. One could bitch about the incomplete High DPI support of the TestInsight window, but that is a rather minor issue.

Make sure that RegisterOldPngFormat is defined in the PngComponents project.

There have been almost 8 weeks between the report (Priority: Major) and the release. Just sayin...

I have just uploaded the sources for the Code Coverage Plugin shown during my session at EKON 22 on Monday. Besides its functionality it may also give some guidance on writing IDE plugins in general. https://bitbucket.org/uweraabe/codecoveragemagician Tested only on Delphi 10.2.3 Tokyo!

These issues should be fixed now. They crept in when I made the necessary changes for the Delphi 11 version. It turns out that having form inheritance for a TDataModule didn't work out well with adding toolbars and actions to the IDE. After I split the images into a separate data module and got rid of the inheritance all worked well as before. Interestingly Delphi 11 didn't suffer from this.

Peganza Pascal Analyzer - the Lite version is even free.

I don't know how others are going to detect code coverage, but I know of AQTime and Nexus Quality Suite (formerly TurboPower Sleuth QA) also have a significant performance drop when too much code is profiled at once. Given that I have no information of your intentions for code coverage, I can only cite the plugins readme: While the TDD approach lets you write tests before code and implement only what is needed to make the test green, reality often has existing code that needs tests. In that case the workflow is to write a test and add test cases step by step until all code paths are covered. That's where the code coverage plugin can help. Just curious, can you elaborate how your are planning to use code coverage for almost the whole project at once? What information are you expecting to get from that?

I doubt that. The code coverage is done by setting a special breakpoint in each code line. That might get a bit slow with 5 million breakpoints. I recommend to do code coverage on one or very few methods at once.

There seem to be problems with the toolbar buttons in all Delphi versions except Delphi 11. In Delph i 10.4.2 there is even a crash when installing the plugin from the IDE. I will try to track that down as soon as my schedules allow.