Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / lazarus / 1999-07

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

6 messages · 4 people ·

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Michael A. Hess
to Baeseman, Cliff: hmmm the dfm should be in xml format so that us or any other language wishing to use a…
Cliff wrote 5 lines
hmmm the dfm should be in xml format so that us or any other language wishing to use a lazarus dfm can do so without having to build a parser. Lazarus will interpret the xml file using a parser to generate the necessary code .inc.

You've lost me here Cliff. How is the compiler suppose to deal with an xml document? Sure the IDE could output the data it is collecting to an XML file but then what? What is the compiler suppose to do with it?

I don't want to have to deliver XML documents along with my application for every form I create.

==== Programming my first best destiny! ==== Michael A. Hess Miracle Concepts, Inc. http://www.miraclec.com

Reply by email

Michael A. Hess
to Michal Bukovjan: I think this is not much usable, because : 1} The storage mechanism caused a lot of pain…
Michal Bukovjan wrote 6 lines
I think this is not much usable, because : 1} The storage mechanism 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.

Show quoted text 6 lines
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. http://www.miraclec.com

Reply by email

Jeff Wormsley
to Michal Bukovjan: I think this is not much usable, because : 1} The storage mechanism caused a lot of pain…
Show quoted text 6 lines
> 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 ***********

Michael A. Hess wrote 38 lines
Michal Bukovjan wrote: > > I think this is not much usable, because : > > 1} The storage mechanism 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.
Show quoted text 10 lines
-- ==== Programming my first best destiny! ==== Michael A. Hess Miracle Concepts, Inc. http://www.miraclec.com _________________________________________________________________ To unsubscribe: mail with "unsubscribe" as the Subject archives at http://www.miraclec.com/list_archives/lazarus

Reply by email

Michal Bukovjan

Hi,

I think this is not much usable, because :

1} The storage mechanism caused a lot of pain in Delphi, because for compound components, it is highly preferable that a TComponent class can remember its state.

2} It is for design-time only. While this may be enough for RAD, 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 !

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.

3) Using the below system, reading of larger pixmaps, sound clips or whatever binary data could be real fun :-(

Just my thoughts,

Regards,

Michal Bukovjan

"Michael A. Hess" wrote 62 lines
wrote: > > > Or are we going to have the RAD generate FCL code that is included > > into the file via an {$I ...} statement at the appropriate place? > > This is a possibility which you can consider, and which would be very > fast; you could make a TForm abstract method called : > > TForm.CreateDesignedForm;virtual; > > begin > end; > > Which you override in the .dfm form: > > TForm.CreateDesignedForm; override; > > begin > SetBounds(X,Y,W,H); // place form > MyButton:=Tbutton.Create(Self); > // and so on > end; > > At the end of TForm.Create you then do a > > CreateDesignedForm; > If Assigned(OnCreateForm) do > OnCreateForm(Self); > // Form Creation Complete. > end; This is exactly what I had in mind. I personally would like to lean toward this directly. It seems to give us more flexibility and it doesn't rely on compiler features to implement it. On the good side it would mean you could manually go in a tweek a components location or some other aspect. The downside is that you could go in a tweek a component location or some other aspect BADLY. It would only require a simple text parser to read in the settings for the RAD and editing the same would be just as easy. If we go the resource route we need to have routines in the IDE that can write and interpret the file data. The compiling would then have to deal with the binobj stuff and would we get into platform issues. Next the code would have to open the resource part of the file to get the data to setup the form. When it all comes down to it I like the idea of a code generated file that is loaded with an {$I...} command. Any other opinions? -- ==== Programming my first best destiny! ==== Michael A. Hess Miracle Concepts, Inc. http://www.miraclec.com _________________________________________________________________ To unsubscribe: mail with "unsubscribe" as the Subject archives at http://www.miraclec.com/list_archives/lazarus

____________________________________________________________________ Get your own FREE, personal Netscape WebMail account today at http://webmail.netscape.com.

Reply by email

Baeseman, Cliff

hmmm the dfm should be in xml format so that us or any other language wishing to use a lazarus dfm can do so without having to build a parser. Lazarus will interpret the xml file using a parser to generate the necessary code .inc.

Cliff

Earlier message 61 lines
-----Original Message----- From: Michael A. Hess Sent: Wednesday, July 21, 1999 1:51 PM To: Subject: Re: [Re: [lazarus] How are we going to store component data?] Michal Bukovjan wrote: > > I think this is not much usable, because : > > 1} The storage mechanism 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. http://www.miraclec.com _________________________________________________________________ To unsubscribe: mail with "unsubscribe" as the Subject archives at http://www.miraclec.com/list_archives/lazarus

Reply by email

Baeseman, Cliff

no i am just referring to the format of the dfm. The ide will look at that and generate the code necessary for the classes.

That means that even glade could open one of our dfm files. Or it could be viewed in a browser.

Cliff

Earlier message 31 lines
-----Original Message----- From: Michael A. Hess Sent: Wednesday, July 21, 1999 3:25 PM To: Subject: Re: [Re: [lazarus] How are we going to store component data?] Baeseman, Cliff wrote: > > hmmm the dfm should be in xml format so that us or any other language > wishing to use a lazarus dfm can do so without having to build a > parser. Lazarus will interpret the xml file using a parser to generate > the necessary code .inc. You've lost me here Cliff. How is the compiler suppose to deal with an xml document? Sure the IDE could output the data it is collecting to an XML file but then what? What is the compiler suppose to do with it? I don't want to have to deliver XML documents along with my application for every form I create. -- ==== Programming my first best destiny! ==== Michael A. Hess Miracle Concepts, Inc. http://www.miraclec.com _________________________________________________________________ To unsubscribe: mail with "unsubscribe" as the Subject archives at http://www.miraclec.com/list_archives/lazarus

Reply by email