Or an option:
{$ifdef nonLazarus}
protected
...
{$else}
private
...
{$endif}
Then MSEgui/FPgui/.. may be compiled with "-DnonLazarus" option
2012/7/21, Ivanko B <ivankob4m...@gmail.com>:
> The problem now is that cracker classes can't be used in future anymore
> because of the new class field ordering optimisation, so I dared to ask.
> ==============
> The guys, this point is important !
> All the discussion members are right in their arguments (Martin's &
> the "community" impatience to fixing bugs etc because of intensive
> using all range of MSEgui facilities- and the need of the FPC team to
> keep the proper class hierachy ) & and neither You nor Martin have
> enough time to chase tons of code to justify every smallest piece JUST
> NOW with hot heads.
> So, is it possible to design the new feature in such way that to have
> an option to proceed using cracker classes ?
>
>
> 2012/7/19, Jonas Maebe <jonas.ma...@elis.ugent.be>:
>>
>> On 19 Jul 2012, at 12:21, _-jan...@web.de wrote:
>>
>>> Unfortunately PACKED is not allowed on all suitable places; there should
>>> be packed set
>>
>> There's the {$packset xxx} directive you can use.
>>
>>> /array/record/
>>
>> "packed array" and "packed record" both exist.
>>
>>> object/class.
>>
>> Both respect the current {$packrecords xxx} setting ("class" only since
>> FPC
>> 2.6.0). If you use {$packrecords 1}, there will be no gaps between the
>> class
>> fields and hence nothing will ever be reordered either.
>>
>>
>> Jonas_______________________________________________
>> fpc-devel maillist - fpc-devel@lists.freepascal.org
>> http://lists.freepascal.org/mailman/listinfo/fpc-devel
>>
>
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
