[fpc-devel] Class field reordering
michael.vancanneyt at wisa.be
michael.vancanneyt at wisa.be
Mon Jul 16 16:50:06 CEST 2012
On Mon, 16 Jul 2012, Martin Schreiber wrote:
> On Monday 16 July 2012 09:35:16 michael.vancanneyt at wisa.be wrote:
>>
>>> The DB components mainly because MSEgui stores string fields as
>>> UnicodeString in datasets and because of the direct data access by index
>>> without scrolling.
>>
>> So you take away the concept of cursor. That is a radical change.
>
> The cursor concept still exists, direct access without scrolling is an
> extension.
>
>> This assumes that all records are always in memory ?
>>
> In tmsebufdataset yes.
I will look at what can be done here.
>
>> The string fields should not necessitate the access of private fields, you
>> can just always create TWideStringField instances ?
>
> TWideStringField probably can not handle the MSEgui storage of UnicodeString
> with variable length in datasets.
> The code of tmsestringfield:
>
> "
> [...]
> function tmsebufdataset.getmsestringdata(const sender: tmsestringfield;
> out avalue: msestring): boolean;
> var
> po1: pointer;
> int1: integer;
> begin
> {$ifdef FPC}{$warnings off}{$endif}
> with tfieldcracker(sender) do begin
> {$ifdef FPC}{$warnings on}{$endif}
> if fvalidating then begin
> result:= (fvaluebuffer <> nil) and (foffset and 1 = 0);
So you need to access to
FValueBuffer : Pointer;
FValidating : Boolean;
I can make these available as protected properties.
> "
>> Maybe we need a function to decide the class of a string field ?
>>
> Probably does not help if the descendant can not access private base fields.
Well, from your code adding the following to the protected section:
Property ValueBuffer : Pointer Read FValueBuffer;
Property Validating : Boolean Read FValidating ;
Should be enough to remove the need for the TFieldCracker ?
Michael.
More information about the fpc-devel
mailing list