Uwe Raabe

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.

I agree that preparing is a good thing, but I would refuse to put that into production.

As already discussed in another thread, using a zero release for production is usually not a good decision. Always wait for the dot 1 release and then decide.

While reading the first one I thought that I would implement that with an Exit instead of using the IsValid variable. So I vote for the second. Less code, less problems. Well, only Thomas can know that.

@Jim McKeeth As it was a Mercurial repo it went down the drain when Bitbucket dropped Mercurial support. It seems I missed to convert it to Git, but I will see what can be done timely to make it available on GitHub again.

This bug was introduced in V15.0.11 when local variables started to detect generic types. Fixed in V15.0.47, which is now available for download.

I can indeed reproduce that here. Investigating...

Cannot reproduce here.

Indeed! I had several occasions where some of these connectors came in handy, but the licensing ruled it out right from the beginning.

Can you file a QP report for those controls?

That comes pretty near to Option to design in Screen PPI but save in 96 PPI Definitely not: https://quality.embarcadero.com/browse/RSP-35301?jql=affectedVersion %3D "11.0 Alexandria" AND text ~ "designer dpi"

It is a different level of flexibility. At the bottom left of the new Welcome Page is a button that allows you to move, resize or even delete the available plugins. In the future this will be extended to add additional plugins and even write your own ones.

No problem over here:

I thought about a global setting, that is taken when the project setting is empty, and omit populating the project settings with the hardcoded default.

I can imagine the bug reports when some day TObject.Destroy actually gets some code and no one will remembers this oversight.

Is there anyone using any Delphi version in its initial release state? (🤡Nice try, but even D7 is widely used with at least one update...)