M.Joos

Thanks Thomas. So the Migration Tool is buggy I guess. Is there already a QC entry for this ?

After I installed D12 I tried to migrate the D11 settings with the Migration tool. Now when I start D12 I receive the following error (and similar ones after that one). Apparently D12 tries to load packages from D11. Does anybody know why this is the case and how to fix it?

I don't think there is an easy solution. If you really wanna go that route, you would need to intercept the instance creation process by e.g. overwriting the NewInstance method of your FrameXY class. Within that you could then add each created instance into a class var array or a class var TList. You could then e.g add a class procedure "SetLanguage" to your class from within you could iterate over all your instances and delegate this call to a regular instance method.

Well, original FMX canvases are very different depending on the platform. While for Android FMX repaints the whole screen, on Windows FMX only repaints the parts that need to be redrawn. In addition to what Vinicius answered, Skia4Delphi is indeed faster on most platforms, especially Android and has a lot of other advantages. But to answer your question, no, Skia4Delphi renders all controls even if only a small fraction has changed. I myself had the same question, and was thinking that it would be more efficient to only render the parts that have changed, but appraently Vinicius and his brother have done some tests and this was not the case. Implementing "dirty region" repainting within the FMX painting framework is not a trivial task - I have looked into it myself, and have abandoded this project for myself (or postponed at least).

AFAIK, they have outsourced at least some parts of their development to a huge center in Ukraine - maybe that's an explanation.

AFIK there isn't a way to achieve this with a plain TLabel. You need to convert your text to a Path (TPathData) and then render this on a Canvas. Google is your friend for more information.

Set the RotationCenter of the TLine either to 0,0 or 1,1 dpending if you want the needle to swing from the top or the bottom.#

My guess: Graphics32 would even outperform this.

Out of curiosity (and lack of imagination this morning), what for might this mechanism be good for other than in the Designer ?

Thanks for the hint - indeed, I fiddled with the migration tool - I think it's usability is very bad. I will look into it, and maybe jsut need to reinstall - haven't done much anyway.

Last week I sucessfully installed D11. Since then I continued to work with D10.4.2 until today when I tried to start up D11 again. Now I received the follwoing error: Confirming this error dialogs leads to many more with similar messages: D11 is trying to load D10.4.2 packages. Does anybody have any good idea why this happens?

From an old blog post from Allen Bauer (https://blog.therealoracleatdelphi.com/2009/09/: " All eligible class constructors and class destructors are invoked in sequence with unit initialization and finalization, respectively. If a given class constructor or destructor is eligible to be invoked (ie. it was linked into your application), it will run immediately before the initialization section for the unit in which the class is implemented. The class destructors will be invoked immediately after the finalization section for the unit in which the class is implemented. Class constructors in a given unit are generally invoked in the same order of declaration, except in cases described below. Class destructors are invoked in reverse order from the class constructors. For an ancestor class declared in the same unit, its class constructor will be invoked before the descendant class constructor and the class destructor is invoked after the descendant class destructor. If the implementation of given class constructor references another class in the same unit with a class constructor, the referenced class’ class constructor will be invoked before the current class’ class constructor. If the references are cyclic (ie. they reference each other in their class constructors), then they are invoked in reverse order of declaration. This means that there can be cases where a class constructor can reference an “unconstructed” class. Ancestor classes from external units used in the interface section are guaranteed to already have their class constructors run prior to any class constructors on descendant classes within the current unit. Unit cycles can break down the deterministic nature of the above rules in the same manner as unit initialization and finalization. However, for a given unit, it is guaranteed that all the class constructors declared within in it will have already run immediately before the initialization section runs. Congruent to this rule is that it is guaranteed that all the class destructors will run immediately after the finalization section. Dynamically loaded packages, using LoadPackage. Because there is no way to know exactly which classes are going to be used, just like there is no way to know which units are going to be used, all class constructors and destructors along with all unit initialization and finalizations are invoked according to the above rules. Other rules about their use are: You do not have to declare a class destructor if you declare a class constructor, and vice versa. They cannot be virtual, dynamic or message. They cannot be explicitly called. They cannot have any parameters. They do not have to be called Create and Destroy. (ie. Init and Fini are equally valid names). With this implementation, it was easier to leverage the same table that the compiler creates for unit initialization and finalization. It satisfies this requirement: “Called automatically to initialize the class before the first instance is created or any static members are referenced.” Issues with cycles are also clearly warned against in VB.NET and C#: “Avoid circular references in Shared … since it is generally impossible to determine the order in which classes containing such references are loaded.” Another benefit is that since it is running during the initialization/finalization phases, any threading implications are no different than the existing rules regarding unit initialization and finalization." What we don't know is, if the compiler behavoiur has changed since then.

Indeed, this is then called "false sharing" and is very well explained from Microsoft's C++ Herb Sutter with an overview here: https://herbsutter.com/2009/05/15/effective-concurrency-eliminate-false-sharing/

For those of you who really wabt to dive deep into timing on Windows I can highly recommend this project with lots of background information: http://www.windowstimestamp.com/

For inspiration you may also look into this excellent answer from Uwe Raabe on Stackoverflow on a related question: https://stackoverflow.com/questions/47347578/manually-skip-a-component-from-being-created-from-the-dfm which also shows a hacky way to prevent components from getting created. I guess Uwe wasn't aware of his answer more than 3 years ago 😉 As for loading the dfm from the resource that's in the executable have a look at http://docwiki.embarcadero.com/Libraries/Sydney/de/System.Classes.TStream.ReadComponentRes