On Tuesday 17 July 2012 09:40:36 michael.vancann...@wisa.be wrote: > > Maybe, but what about performance? Another complication is the > > "updatebuffer" with the "oldvalues". > > Thinking about it: > > I would allocate the buffer as is, with for all string fields an > integer-sized slot in the buffer. The slot contains an index, pointing > to a separate array of strings containing N*M*2 strings. (N=number of > records, M= Number of string fields per record, factor 2 for old values) > > Field value = Element [Index [+1 for old value]] in the array. > where the [Index] is stored in the buffer. > > The speed performance penalty of this system should be negligable, since > you assume all records are in memory anyway. > > And: everything can be done without meddling with the internals of TField. > Thank you. There are more items in the db.pas list... But I think first we should concentrate on classes.pas because I really don't want to fork it. Forking db.pas is less problematic and I probably prefer it in place of an endless discussion and in my eyes not optimal solutions. With a forked db.pas I can eliminate the many workarounds I already had to implement.
Currently needed crackerclasses by MSEide+MSEgui: Used by MSEide for different tasks (example: ask for ancestor forms and frames/submodules while loading a form/datamodule, recover in case of an error) and for streaming of frames with additional components/widgets: TComponent: - FComponents - FComponentState - FFreeNotifies TWriter: - FPropPath - FAncestors TReader: - FStream - FLoaded Used in order TParams create tmseparam items instead of TParam: TCollection: - FItemClass Used to unify memorystreams/files/pipes/sockets/stringstreams: THandlestream: - FHandle TMemoryStream: - FCapacity Why must these fields be private? Thanks, Martin _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel