[Re: [lazarus] How are we going to store component data?]

[Michael A. Hess]

Michal Bukovjan wrote:
> 
> I think this is not much usable, because :
> 
> 1} The storage mechanism starts at TForm. This caused a lot of pain in
> Delphi, because for compound components, it is highly preferable that
> a TComponent class can remember its state.

I'm afraid you have me confused here. What pain is there in Delphi
because of this????

What do you mean, 'preferable that a TComponent class can remember its
state'? What state are you talking about?
 
> 2} It is for design-time only. While this may be enough for RAD,

This is all it is good for. That is all it is used for in Delphi.

> the Delphi system allows for much more flexible run-time behavior, you
> can stream the component (and its children) to an arbitrary stream,
> send over whatever you like {pipe, file, DCOM/CORBA connection, shared
> memory) and make use of the component state in another instance, or
> another app altogether. Not to mention storing component's state in a
> database BLOB !

There is nothing that will prevent you from doing that. The data that is
stored in the resource in a Delphi app is not modified by the runtime it
is used read only. If you are doing any of the above it isn't because it
is part of the basic RAD form design features of Delphi.

> While the binary stream-out may not be the best solution (i.e. XML
> might be better), I suggest we use some sort of streaming technique.

That would require additional files be delivered with the application,
one for every form that you design for the program. This isn't something
I want to do. When I build the application I just want to be able to
deliver the executable and nothing else.
 
> 3) Using the below system, reading of larger pixmaps, sound clips or
> whatever binary data could be real fun :-(


Why?? I'm confused by your whole email.

-- 
==== Programming my first best destiny! ====

Michael A. Hess      Miracle Concepts, Inc.
mhess at miraclec.com   http://www.miraclec.com