[fpc-devel] Class field reordering

Martin Schreiber 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
> make
> > 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
> members)
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 
MSEide+MSEgui extensions:

- FComponents
- FComponentState
- FFreeNotifies

- FItemClass

- FHandle

- FCapacity

- FPropPath
- FAncestors

- FStream
- FLoaded

- FConnected

- FValidating
- FValueBuffer
- FOffset
- FFieldno

- FFieldno

- FBound

- FDatasources

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.

Thanks, Martin

More information about the fpc-devel mailing list