FMX.Dialogs basically blocks mixing VCL with FMX…

Nice find:

Stefan Glienke+4

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]