RTTI info for a class declared in the "implementation" section

Hi all,
I am guessing the answer will be a negative but for Berlin (XE 10.1), is it possible to get RTTI information generated for a class that is declared in the implementation section of a unit?

I did try to google it but couldn’t get my google-foo right.

Thanks in advance,

Not sure if it will work but you could try using this

{$RTTI EXPLICIT METHODS([vcPublic,vcPublished]) PROPERTIES([vcPublic,vcPublished]) FIELDS([])}

Actually giving it full RTTI

{$RTTI EXPLICIT METHODS([vcPrivate..vcPublished]) PROPERTIES([vcPrivate..vcPublished]) FIELDS([vcPrivate..vcPublished])}

and that didn’t work :confounded:
Just going to go with that it can’t be done.

Hi Nick

What if you put the class you need RTTI info for in another unit (in the interface section) and use that unit in the original unit?


1 Like

That would work fine, as moving it to implementation of the current unit does the job.

The only reason I would like it moved to the implementation section is because it is a class that is only used in a single unit test (using DUnit), so my preference is to place it in to the implementation section but if the class needs to be in interface section, then so be it. Not the idea outcome but can live with it.


If you put the test class into TestUnit.pas and put TestUnit in the implementation uses clause of your current unit would your problem be resolved?


Hi Graeme,

My “issue” is that the class doesn’t need to be in the interface section, as there is no other reference to it outside of the actual unit test (the unit test class is all in the implementation section). With that, it should be in the implementation section but since Delphi doesn’t generate the required RTTI when it is in the implementation section, I have to keep it within the interface section.

While I could put the class in to another unit (in which it will have to be in the interface section), it would have the required RTTI. But since it is only used in the one unit, I might as well keep it with the unit test.


How is the ‘private’ class you want to test reflected in the public interface of its unit ?

I generally create a test interface inheriting from the real interface with the ‘hidden’ bits available only in the test interface and then test against that.