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: TComponent: - FComponents - FComponentState - FFreeNotifies TCollection: - FItemClass THandlestream: - FHandle TMemoryStream: - FCapacity TWriter: - FPropPath - FAncestors TReader: - FStream - FLoaded TDatabase: - FConnected TField: - FValidating - FValueBuffer - FOffset - FFieldno TFielddef: - FFieldno TParam: - FBound TDataset: - 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 afterwards.". 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 _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel