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

[Jeff Wormsley]

>> 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.
>

It sounds here like he's saying that by embedding graphics and sound into a resource file, that is then compiled into the executable, would be hard to do.  If I am not totally off my tree, the dfm is a descriptor of how to build and access the resource file.  

However, I don't see the maintenance of this as an FPC include as being a drawback.  Convert a dfm to text with the utility, and tell me what difference it would make (aside from speed) to store this data in a binary format, or store it in a constant structure as fpc code.  It actually should simplify things somewhat, since what is completely hidden in Delphi (resource management) is made available to everyone in lazarus (include files).

Jeff.


*********** REPLY SEPARATOR ***********

On 7/21/99, at 2:51 PM, Michael A. Hess 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?
> 
>> 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.
> 



>-- 
>==== Programming my first best destiny! ====
>
>Michael A. Hess      Miracle Concepts, Inc.
>mhess at miraclec.com   http://www.miraclec.com
>
>_________________________________________________________________
>     To unsubscribe: mail lazarus-request at miraclec.com with
>                "unsubscribe" as the Subject
>    archives at http://www.miraclec.com/list_archives/lazarus