Leaderboard

Not quite. See for instance Ohh...WinUI3 is really dead! - When can we expect the announcement? · microsoft/microsoft-ui-xaml · Discussion #9417 The Microsoft strategy for GUI App development is utterly messed up: WinForms WPF Xamarin Forms UWP WinUI3 MAUI And there is no longer a GUI designer. You have to develop XAML in a text editor. Discussion: WinUI 3.0 XAML Designer · Issue #5917 · microsoft/microsoft-ui-xaml

So that it is found in the controls list of the control or component vs the components list of a form or application.

I just wanted to provide a real-world example why developers decide against implementing WinUI 3. We found easier and (for us) more robust paths for implementing technology that we (=our customers) need in our applications. At the end we have a business to run - WinUI 3 won't put more money in our pockets. - I'm still talking about our little world here and not Delphi in general. But I should also add that I see desktop apps in general as a dying species and expect more transition to web based apps. Your demand for new technology seems to be completely different compared to ours. And that's of course absolutely fine.

By "3rd party" I mean 3rd party libraries. They seem to have all abandoned WinUI3. Likely because there isn't any demand from their customers. Come on. That document is 6 years old but even if it was written yesterday it wouldn't make WinUI3 any more relevant. Try harder. How does the existence of XAML Islands "prove" a demand? Do you understand that "prove" implies that "proof" exists? My mention of Clipper was in reference to your hyperbolic claim that "Embarcadero has been a leader in wrapping and integrating native APIs". If anything they have been known for lacking behind their peers, such as C++, C# and Java in this regard, so how can they be a leader? Delphi is very good at wrapping native APIs but the potential future existence of these wrappings doesn't make it a leader. They have to actually exist. Anyway, I've already spent more time on this topic than I care. Peace Out.

DLL_PROCESS_ATTACH should be in the same thread that calls LoadLibrary(), but DLL_PROCESS_DETACH is not guaranteed to be in that same thread. Raymond Chen even blogged about this issue back in 2009 (emphasis added by me): The thread that gets the DLL_PROCESS_DETACH notification is not necessarily the one that got the DLL_PROCESS_ATTACH notification

Hi This one can be a good choice too : it's a "how to create FMX programs" with simple sample projects. https://delphi-books.com/en/Delphi-Programming-Projects.html