[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