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

1

4

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'}
Imidazole answered 28/6, 2012 at 17:37 Comment(5)
@KenWhite, Remy Lebeau just did. :)Toe
Well it's either unanswerable (your opinion) or obvious (Remy) or there may be More Here that we can figure out from the use of Delphi (my reason for asking). Please do vote to close, or answer this, if you can.Imidazole
@François, not really. Remy repeated the docs, and an important part of what Warren is asking is "In a future version...perhaps a similar marker would allow" - unless we're inside EMBT with info on future plans, speculating on "a future version" is discussion and therefore inappropriate here. :-) And Warren, I did, as I said 7 hours ago - was your comment meant for me? Note I did not downvote; the question was well-asked, but just not appropriate here. Bugs (even docs ones) belong at QC, and fortune telling belongs wherever psychics congregate. :DAntietam
I consider this an architecture question; Understanding the Delphi toolset.Imidazole
I guess it really is Obvious, as Remy says.Imidazole
P
9

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.

Paw answered 28/6, 2012 at 21:10 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.