Hello, FPC developers' list

I had discussion with Marc about how to mark some properties as widgetset specific (and show them in object inspector as specific for widgetset 'xxx'). As result of discussion we found easy solution - mark that properties with platform flag, but platform flag should be extended to support list of platforms.

Examples:

TMenu = class(...)
published
  property Detachable: Boolean read ... write ... ; platform carbon qt;
{ or it can be platform 'carbon,qt' or another easier way }
end;

As result of such declaration RTTI for TMenu will have platform list array with values 'carbon' and 'qt'. If there was no array of platforms in declaration, then only platform flag will be set in RTTI with empty array of platform list.

What fpc developers think? Is it hard to implement?

Best regards,
Paul Ishenin.

I think it's better to implement a string message dispatcher for this instead of adding RTTI (which is already bulky as it is). Do not forget that the widget set is very lazarus specific, and has nothing to do with RTTI or even the OS/CPU platform that the compiler knows.

So as far as I'm concerned, this is more of a no-no.

Michael.

We can add some hint ofcource like {%widgetset carbon qt}, write special parser for that, invent same as rtti structures to store string array of supported widgetsets. OR it can be easyly fited into existed platform keyword and without inventing second weel existed RTTI structure can be extented with arrat of string.

If it is not lazarus but say component set developed for several platforms (libraries, os, whatever else) then platform string can be 'win32 linux osx' (if property is valid only for 3 os) or 'oracle interbase' (if property is valid only for 2 databases).

Another advantage is that with extra info in platform keyword fpc will have more informative platform hints.

I see no disadvantages.

Best regards,
Paul Ishenin.

Where does the list of allowed values come from? How are the values validated during compilation (what happens if someone types 'qr' instead of 'qt' by mistake)? What would be the value of information stored this way if there's no validation at all?

Tomas

The informativeness of 'platform' hints could be improved by including a comment that is adjacent to the keyword, if one exists, e.g:

property SomeProp; platform; // qt and carbon only

Then hint will then be:
property 'SomeProp' is platform-specific (qt and carbon only).

But this stuff REALLY has nothing to do with runtime...

Sergei

Some comments inline, imo, no need to comment on separate mails.

This is optional. RTTI is info is already stored pretty compact. Only when specified this info can be added.

>>> Do not forget >>> that the widget set is very lazarus specific, and has nothing to do >>> with RTTI or even the OS/CPU platform that the compiler knows.

The example Paul gave is about widgetsets, but it could alse be use for indications of OS or CPU for instance.

When used for visual tools like lazarus, the RTTI is imo the only place to store this kind of info, but...
The platform directive is not bound to published properties only. That would mean that is has to be stored in the ppu somewhere. (support for the platform directive has to be stored in the ppu anyway) OTOH, you could say that this is an extention for published properties.

>>> So as far as I'm concerned, this is more of a no-no.

What is the fun of the RTTI anyway ?

>> We can add some hint ofcource like {%widgetset carbon qt}, write special >> parser for that, invent same as rtti structures to store string array of >> supported widgetsets.

Besides, the parsing for this will become difficult when only compiled units are used.

It is a kind of user feedback. And if someone had typed qr, then it will get noted that that property/routine is only valid for qr. Its a hint, not something enforced by the compiler.

Indeed, but then you have to scan comments. Which will be gone once you compile the unit.

But this stuff REALLY has nothing to do with runtime...

The hints itself not. I agree.
But when doing RTTI, I might want to give the user some feedback. In the current situation I've no option for that.

Marc

Time to introduce pragmas? Something like

    pragma Platform (SomeProp, 'qt, carbon');

or in more general terms:

    pragma <Pragma_Name> (<Identifier>, <Property> [, <Property>, ...]);

perhaps?

Regards,

Vinzent.

So using this example: Detachable property information will be written to the lfm file for carbon and qt platforms. What is going to happen if that lfm file is loaded (as in x-platform applications) under a Windows or Linux-GTK system? "Unknown property error" on load in Lazarus??? And when saved under the later platforms, Lazarus will auto remove that unknown property from the lfm file like it does with other unknown properties?

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

No the property will always exist and always been written. Only an indication to the user can be shown that this is a property which might not work on all platforms
IIRC, that's what the platform directive was meant for.

Marc

Only to say that code is platform specific. You get this only when compiling.

Note that what you ask goes way beyond platform: you ask widget-set dependencies. You should encode this kind of information in your interface class, not in the RTII.

Michael.

If RTTI (RTII= run time interface information ? ;-) )is out of the question, maybe it is a better place to add it to the fpdoc documentation for that property/class and let the IDE read that information from there.

Vincent

And you don't want to know in what case it is specific ?

Note that what you ask goes way beyond platform: you ask widget-set dependencies. You should encode this kind of information in your interface class, not in the RTII.

we ask some way through code to be able to generate hints to the user when certain feature is used.
Note that using it is the key here, not the presence of the feature.

Marc

Not really, e.g.

- make sure that the compiler can parse the platform list easily. (e.g. some form of brackets "platform [ident1,ident2];")
- pass the compiler a set of allowed strings, to catch misspellings.
- generate some table with all the accepted strings, and the let the RTTI refer to it.

You should encode this kind of information in your interface class, not in the RTII.

However I don't like the RTTI principle either. PPU ok, but not RTTI. There is enough dead/rarely used data in the binary as it is. It is only a matter of time till the next "easy" idea pops up.

You have this kind of mechanism with the message string table, if you really really need it, I suggest it is handled there.

This is exactly why I am not keen on adding this to RTTI.

Michael.

Note:
You can write a property editor for the property. A property editor can hide a property in the OI or give hints. Or the TPropertyEditor can be extended with a hook, so that the IDE can ask the widgetset, if a property should be shown.

Mattias