Martin Schreiber wrote 9 lines
On Monday 23 July 2012 13:58:56 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.
Show quoted text 23 lines
[...]
>> 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.
Show quoted text 35 lines
>> 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.
