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

[michael at tfdec1.fys.kuleuven.ac.be]

On 21 Jul 1999, Michal Bukovjan wrote:

> > 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?
> 
> There is no pain in Delphi now, because from Delphi (2?) up you can stream out
> just any component. But way back in Delphi 1, this was a major drawback.
> </THEORY> I am talking about a persistent state of objects, which is a great
> thing to have - it means that the object has easy and STANDARD way to remeber
> its attributes before it is destroyed and is able to retrieve them back when
> it is created again. (See the awkward way how to accomplish this in COM,
> various discussions on Delphi forums, etc.}.
> <THEORY/>
> As I understood, the CreateDesignForm is created by IDE to be compiled into
> the project as a virtual procedure and later called from the constructor.
> While this is sufficient for basic IDE RAD, the TForm is still a SPECIAL case
> and a more generic approach (Delphi-wise) is what should be in here.

Not to mention that it doesn't allow you to specify a bitmap for a TBitmap;
You cannot get that in pascal source.

>  
> > > 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.
> > 
> 
> Maybe you are right, I do not have the Delphi sources. How do you think they
> copy components via clipboard? Anyway, that is NOT all it is used for by
> Delphi programmers (me included), trust me. Consider how easily can be done a
> custom report design (for printing, by end-users) in Delphi applications ...

Haha :). My biggest project is an end-user report designer; it streams all
designed reports into a compression stream; which is read again when
the report is read from disk... VERY convenient. No custom code to read/write
a report from/to disk, just a simple

  Stream.WriteComponent(FReport)

and voila. The lazarus IDE need do nothing more than this when creating
forms.

> 
> > > 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.
> 
> But the RAD in Delphi USES that mechanism. See component streaming support in
> TStream and its descendants, TFiler, TReader, TWriter objects. The .DFM file
> is just a component hierarchy having its persistent state written into a file.
> So the Delphi IDE makes heavy use of these features, in fact it is build upon
> it.

Very much true; it uses streaming to copy&paste all form components from&to 
the clipboard. So do I in my application.

> 
> > 
> > > 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.
> 
> I think you can link that into the executable, which is a part done by linker,
> but I am not expert in this area, so you are probably right.
> 
> However, the streaming techniques on which is Linux build, simply fascinates
> me. Through streams in XML format, you could even stream TForm or TGroupBox or
> whatever out of Lazarus to a WWW server, creating a WWW page !!!

the XMLRead and XMLwrite units have been changed so they can read/write to
streams; in principle you could open a compression stream on top of a 
socket stream to a remote server, and stream your whole form to it in XML.

All these streams are available already. (except the socket stream :( )

> 
> >  
> > > 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.
> 
> How would you represent a bitmap or a sound clip in text? BASE-64 or
> MIME-encoding? or these nice numbers Delphi shows when you open a 
> .dfm? Could
> be fairly large, and I am not sure about compiling efficiency then.

I think he has a point here, and that the best shot is:

1) A DFM file is a description of the form in DFM - you can easily make a bit
   representation of a bitmap in XML - 
2) when compiling the app, the XML gets translated into resources by a   
   special resource compiler - Delphi has one too - which are linked in 
   in the application.
3) This resource is linked in the app, and read by the TForm startup code.


> Maybe we still don't understand each other, in which case I apologize and beg
> for further explanations.

at least I understand you perfectly, I assume the others got the pictuir
also now ?

Michael.