[Lazarus] Codetools check lfm bug?

[patspiper]

On 22/02/13 18:51, Mattias Gaertner wrote:
> On Fri, 22 Feb 2013 18:07:05 +0200
> patspiper <patspiper at gmail.com> wrote:
>
>> Hi,
>>
>> 'Tools/Check LFM File in editor' gives the error 'identifier Strings is
>> not published in class TStringListDescendant'
>>
>> where TStringListDescendant is just a descendant of TStringList. The
>> error does not happen with TStringList itself. Is this a bug?
> It's not yet supported.
> The Strings property is a runtime property, so there is
> no clean way to find it at design time.
TStringList is a descendant of TStrings, yet a published TStringList 
property does not exhibit the error. What makes TStringListDescendant 
different?
> I can imagine several
> heuristics which could solve this. But since you are the first to ask
> for this in 10 years, I'm not sure if it is worth the hassle.
Check lfm by itself is not of much use. I encountered the issue while 
testing the Delphi converter (which checks the lfm/dfm). The converter 
chokes on it. I can try to code a solution if you guide me.
>
> I added a semi hack:
> Please update svn trunk to 40366. Then call in your designtime package
> register procedure:
>
> uses
>    FormEditingIntf;
> ...
> procedure Register;
> begin
>    FormEditingHook.RegisterDefineProperty('TStringListDescendant','Strings');
> end;
The lfm passes the Check lfm in editor using the semi hack.

Stephano