[fpc-devel] Class field reordering

michael.vancanneyt at wisa.be michael.vancanneyt at wisa.be
Mon Jul 16 09:35:16 CEST 2012

On Sun, 15 Jul 2012, Martin Schreiber wrote:

> On Sunday 15 July 2012 19:21:58 Michael Van Canneyt wrote:
>> On Sun, 15 Jul 2012, Martin Schreiber wrote:
>>> Currently I need access to the following private FCL class fields because
>>> of MSEide+MSEgui extensions:
>> I have looked at your list. (I sent my previous mail about this without
>> having seen the list)
>> At first sight, I see no reason to make any of these fields protected.
> Jup, I feared it. ;-)

I wrote 'at first sight', because without explanation I don't know what you
try to achieve.

>> For example:
>> TParam.FBound
>> Is directly accessible through TParam.Bound, so why on earth would you need
>> to have it protected ??
> Hmm, this probably is a mistake from me. Was it writeable in all FPC versions?

This I don't know. At least, now it is writable.

>> Can you give some explanations at least of what you're trying to do,
>> maybe we can find workarounds for your problems ?
> Before I started to use cracker classes I searched workarounds for weeks or
> even months already...

2 pairs of eyes always see more than one.

> If you want you can grep the MSEide+MSEgui sources for "cracker" in order see
> what I do with them.

That does not tell me why you do something ?

> TComponent, TWriter, TReader for example because in
> MSEide+MSEgui one can place additional components in an inserted tframe and
> combination of inherited frames and inherited forms need special handling.

Basically, you want to drop a component on a Form containing a frame, and make 
it's owner the frame ?

> 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.
This assumes that all records are always in memory ?

The string fields should not necessitate the access of private fields, you can 
just always create TWideStringField instances ? 
Maybe we need a function to decide the class of a string field ?

> The stream components because in MSEgui there is a single hierarchy for file
> and memory stream so the more specialized descendants (ttextstream,
> ttextdatastream) can work on files and on memory.

I'm sorry, I don't understand what this means ?


More information about the fpc-devel mailing list