On Mon, 23 Jul 2012, Martin Schreiber wrote:
On Monday 23 July 2012 13:58:56 michael.vancann...@wisa.be wrote:
These fields must remain private to ensure proper functioning of the
component system. Too much depends on the proper functioning of the
notification API and the owner/owned relations and its inherent memory
management.
That is one of the reasons I need the full control. Please remember, the
properties are "deprecated".
You ask to throw away the very purpose and reason of existence for TComponent.
This is not going to happen.
The 'deprecated' does not change that. These fields are private for a reason.
Making them protected exposes them e.g. in TForm and TDatamodule from
Lazarus, which is a can of worms we are not going to open.
Please explain the actual problem. Till now you explain your solution to a
problem
you seem to have, not the problem itself. You hide behind other 'potential'
problems.
And in general:
if TComponent imposes such restrictions on what you want to do: Simply do not use it.
There is nothing sacred about TComponent. Lazarus for instance only requires TPersistent.
This is not as bad or such a big obstacle as it may seem: The tiOPF
framework has written a complete class system without referring to
TPersistent or TComponent, it uses RTII successfully.
It works very well, I use it myself.
I don't see why you cannot do the same. It's perfectly possible to use the
streaming system for both TComponent and other classes. All it takes is
RTTI, which happens to be enabled in TPersistent.
If we need to make some adjustments in TFiler so it will treat additionally
other classes as it currently treats TComponent, we can do that as well.
This should not be hard to do. You probably only need 3 things:
- Decide (based on a class) whether to descend in a component or write a
reference.
- Set the name.
- Set the owner/parent.
These operations can be moved to virtual methods, and then the streaming can
stream a TComponent as well as a (supposed) TMSEComponent tree.
[...]
Is it possible to add
"
protected //for toolkit access only
property HandlePrivate: THandle read FHandle
write FHandle; deprecated;
" to THandleStream
No problems here. We can do this as well, provided we can make the
signature slightly different:
protected
Procedure SetHandle(AHandle : THandle); virtual;
property HandlePrivate: THandle read SetHandle
SetHandle will just set the FHandle fields, but I want a virtual setter
so descendent classes get a chance to react on the change in case they need
to.
Then SetHandle() is sufficient.
Fine.
and
"
protected //for toolkit access only
property CapacityPrivate: PtrInt read FCapacity
write FCapacity; deprecated;
" to TMemoryStream?
TMemoryStream.Capacity is already read/write.
Why do you think you need direct access to the field ?
"
TMemoryStream = class(TCustomMemoryStream)
private
FCapacity: PtrInt;
procedure SetCapacity(NewCapacity: PtrInt);
protected
function Realloc(var NewCapacity: PtrInt): Pointer; virtual;
property Capacity: PtrInt read FCapacity write SetCapacity;
procedure TMemoryStream.SetCapacity(NewCapacity: PtrInt);
begin
SetPointer (Realloc(NewCapacity),Fsize);
FCapacity:=NewCapacity;
end;
"
The reason is to replace the memory without to trigger Realloc(). Used in the
internal memory stream of tmsefilestream. tmsefilestream.create() behaves as
memory stream, tmesefilestream('thefilename') as file so the descendants
(ttextdatastream for example) can work with all the different stream kinds
and inherit from TStream.
If it is internal to tmesefilestream, why don't you create your own descendent
of TCustomMemoryStream ? If it is for this purpose, then it seems to be far
easier to use that technique than to request this change. There is nothing
magical about TMemoryStream.
Michael.
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
