[fpc-devel] Class field reordering
mse00000 at gmail.com
Sun Jul 15 08:58:53 CEST 2012
On Saturday 14 July 2012 19:55:39 Sven Barth wrote:
> > I sometimes need "cracker" classes in MSEide and MSEgui to fix bugs and
> > extensinsions for FCL classes in order to access private fields (examples
> > TDataset, TParam, TField, TFiler, TReader, TWriter, TComponent).
> > Is it guaranteed that the local definitions have the same layout as the
> > definition in the FCL unit?
> Do you have current examples where you fixed bugs? Maybe these can be fixed
> at the source which might be better than making them protected (though this
> can still be done for non-bug fields where you need access to certain
MSEgui must work with current FPC release so sometimes it is necessary to make
workarounds until the next FPC release with the bugfixes. As soon as possible
I remove unneeded cracker classes.
I report all FPC bugs I find apart from the compiler crashes by partial
compile where reproducing is difficult, needs the whole MSEide+MSEgui source
and fixing probably would need construction of a new unit handling in FPC.
Bugs which are Delphi compatible are not reported also. ;-)
Currently I need access to the following private FCL class fields because of
I hope I didn't forget anything. Suggestion:
For all FCL base classes which are used in different toolkits and which can't
be forked without breaking precompiled third party components, namely the
units classes and db, move *all* private fields and methods to protected and
mark them as "Use on your own risk, can be changed everytime! Don't cry
I can not fork the listed components because of compatibility with third party
components. On the other had I forked SQLdb completely when the workaround
burden became too big.
More information about the fpc-devel