What does TDataModule.ClassGroup pseudo-property in Delphi XE2 really do?

Question

I tried to copy and paste a component from one data module into another in Delphi XE2. The component was a Fast Report data source link component. The data module was brand new, just created that second, in XE2.

Someone else had the same problem and reported it on quality central as 106369 and same error message leading me to this mysterious DocWiki entry.

So data modules now have a framework affinity, and a designtime-only pseudo property, which according to the docs:

"Because the ClassGroup pseudo-property is used only by the IDE and is not a compiler-generated property (hence, 'pseudo-property'), ClassGroup is not documented in the compiler-generated Libraries Reference. The page you are reading is the documentation for ClassGroup."

So, the first time I even learn this exists is when it blocks me from copy and pasting components into my data module from an existing set of designtime building blocks that I didn't wish to rebuild from scratch.

Once I change the data module affinity, I can paste stuff into data modules without it bugging me. Thank goodness for Google-that-error or I'd be stuck.

If it is intended to help us write cross platform data modules, and yet it only affects the IDE, according to the documentation, that's inconsistent with the warning that you get when you play with this at designtime, here's the error you get if you change it:

 EInvalidType : The following component(s) are not available in the specified 
 class group. This is likely to cause compile or runtime errors. 
 frxDBSet.TfrxDBDataset.

What I can't see is how that error message can be correct, and the documentation can also be correct.

The warnings seem to suggest compile, link, and runtime errors if this is set incorrectly. Curious minds who want to know what's really going on, want to know: What is this thing about and why did it get added to the data modules in XE2. I anticipate other people will stumble upon this weird feature, with the feeling that they've stepped in something like dinosaur droppings, and want to know what is up with this feature.

My best answer at this point is that a data module affinity for TPersistent which means, in XE2 lingo, that this data module doesn't want non-visual controls in it, that are VCL-specific. In a future version of Delphi, perhaps a similar marker would allow us to mark forms as being "clean of dependencies on the VCL or windows" too?

Update 1: The .PAS source code of your data module stores this pseudo-property in a way that looks a bit like a compiler directive, like this:

implementation

{%CLASSGROUP 'Vcl.Controls.TControl'}

Answer 1

I think it is pretty obviously what its intended use is for, and the documentation you link to is pretty extensive about that purpose.

It is meant to prevent VCL-only components from being placed on a FireMonkey-accessible DataModule, and vice versa.

Since TDataModule is initially framework-neutral, only framework-neutral components can be placed on it.

So obviously, your source DataModule has a different affinity than your new DataModule, which is why copy/paste does not work until you change the affinity of the new DataModule to match the affinity of the source DataModule.