FMX.Dialogs basically blocks mixing VCL with FMX…
Posted by jpluimers on 2017/04/27
Nice find:
Look into the initialization block of FMX.Dialogs. The call to ActivateClassGroup(TFmxObject); turns off all the TRegGroups that don’t contain at least one type that inherits from TFmxObject which also happens to be the group that you register your form class to. GetClass then ignores such groups.
I don’t have the slightest idea what the intention behind all that code is but it certainly is one of the reasons why you cannot mix FMX and VCL officially.
In response to:
I have an VCL application. I need to register some form classes at run time. This is done in the form’s unit implementation section :
Initialization
If GetClass(‘TfmConnectiondialog’) = Nil Then
Classes.RegisterClass(TfmConnectiondialog);Suddenly my class wasn’t registered anymore. GetClass(‘TfmConnectiondialog’) was always nil and Classes.RegisterClass had no effects.
After some long search, I’ve found that I’ve inadvertently added an FMX.Forms in one of my unit. This was the culprit. Replacing FMX.Forms with VCL.Forms solved my problem.
Behaviour is really strange, why Classes.RegisterClass didn’t throw any exception ? Is this a “Bug” or is this “as expected” ?
–jeroen
Source: Hello, I have an VCL application. I need to register some form classes at ru… [WayBack]
davidberneda said
Calling again ActivateClassGroup(Vcl.Controls.TControl) and then RegisterClass(TForm1) should work fine. (I do this in many TeeChart units initializations, to allow duplicate class names coexist at my fmx and vcl packages loaded/mixed at design-time)