Uwe Raabe

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.

I didn't have these problems. All 3rd party libraries I use come with sources and can be adapted to a new Delphi version in a reasonable time frame even without any help of the vendor. Usually I can compile my main project within 1 - 2 days after the first beta drop. There are differences in the effort needed for each library, though. Not everyone took an update friendly approach.

I missed to push a commit. Should work now with the latest change.

Simply because I started with Tokyo and updated to newer versions only. I will see how far back it can work without too much of a hassle.

@Jim McKeeth Here it is: Delphi Code Coverage Plugin

Fine (well, somehow). Does it happen only on Win7 or can you see that on Win10, too?

I'm afraid that may be out of my scope here. Delphi 11 states it requires Win10+ and the error occurs with Win7 inside System.TypInfo.GetEnumName, but it does not happen here in Windows 10. If you can reproduce with Win10 I will try my best to reproduce it on my side. Sorry, but I'm not going to install Delphi 11 on Win7 here to trace a bug in an unsupported environment.

Who says that they weren't? Edit: To get a hint, just check the open QP entries for Delphi 11 created before the release date: https://quality.embarcadero.com/browse/RSP-35310?jql=status in (Open%2C "In Progress"%2C Reopened%2C "Needs feedback"%2C Reported) AND affectedVersion %3D "11.0 Alexandria" AND created <%3D 2021-09-09

I don't share this opinion, but hey, readability is highly subjective, isn't it?

Others.

There were no public versions released between 15.0.38 and 15.0.44. Unfortunately 15.0.44 contains all the changes necessary for the High DPI support in Delphi 11. This results in nearly 300 changed files in the project. Without any clue where to look at it is almost impossible to guess what is happening. Can you track it down to the co-existance with any other plugin or design package? That would narrow down the test scenario to reproduce.