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 ?
Michael.
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
