As Shane already said, LFM files are just DFM (Delphi Form) files. If you need the exact format, I can mail you a description I've used for myself for the Free Pascal streaming code.

I want to participate in writing the object inspector for lazarus and looked up for documentation. The current lazarus code creates LFM files which looks like DFM files, but the web page says:

"... we are also working on the layout and design of the LFM file which is comparable to the Delphi DFM file. We are using XML as the file format. This is so that other layout engines will be able to read and modify the LFM form. For example it would be possible to use a modified version of Glade to edit an LFM file if you like using it better than the built in tools."

Thus I was confused and wrote the mail.
I am glad to hear that LFM = DFM, since the format is simple and clear. Please mail me your description of the format.

BTW, for what is your streaming code? Is it part of the free pascal compiler or is it for lazarus?

Mattias

You are right, only the binary format is a problem (and a big mess). But as normally DFM files are binary files I referred to binary files, sorry.

But here is the description for the binary DFM format, to end the discussion (hopefully):

-----

DFM files consist of:

|- Header
|- Form: Binary serialised object

DFM Header
----------
Byte Value 255 ($FF)
Byte Value 10
Byte Value 0
? Byte Null terminated string: Resource name, in DFM's this is always the type of the form in upper case.
2 Bytes $1030
4 Bytes Size of binary serialisation in bytes

Binary serialisation
--------------------

- Signature
4 Bytes: "TPF0"
- Form object
|- Properties
|- Sub objects
|- Properties
...

Objects
-------
- Header
ONLY when ffInherited and/or ffChildPos would be set to 1: Byte TFilerFlags
Bit Meaning
0 ffInherited
1 ffChildPos
2-3 unused (0)
4-7 always 1 (==> presence indicator for this byte!) When ffChildPos is set:
Int ChildPos (Index of child in array)
SStr Class name
SStr Object name
- Properties
For each property:
SStr Property name
Value: TValueType, followed by the value itself
vaString
Simple ShortString (length byte + string)
vaLString
???
Identifer
Simple ShortString (length byte + string)
Integer
Byte -> vaInt8, vaInt16, vaInt32, followed by 1/2/4 value bytes Float
vaSet
List of ShortStrings, terminated by an empty string ListBegin / Values / ListEnd
Binary
4 Bytes length of data, followed by the binary data vaCollection
|-List of:
| (Optional) Integer: Order
| ListBegin
| Property list
| ListEnd
|-ListEnd (0 byte)
- List End
Byte vaNull (0)
- Sub objects
-> recursively (Header, Properties, Sub-sub objects etc.)
- List End
Byte vaNull (0)

-----

- Sebastian

There are 2 streamers currently implemented as far as I know:
- one binary streamer
- one text streamer.
There are plans for a third streamer (maybe it is already finished, I don't know) that would read/write XML.

Michael.

There isn't any info. It was based on the layout of the DFM files.

What's your interest in them?
Shane

But this is what everybody already said.

But as far as I have seen: The RTTI can't store the values in the program on disk, can it?

Sorry but it seems that you don't really know what RTTI is about: RTTI, the Run Time Type Informations, is just a concept for being able to access informations about types (such as classes) at runtime of a program. More concrete, for classes this means that you can get a list of all published properties and methods at runtime, together with informations about all referenced types.

Under Delphi changed values are stored in the DFM file and compiled in via the {$R *.DFM} directive. Which is a much better solution than to store it in the Form.Create method (see examples).

This is not very exact: Delphi creates an instance of the form in the designer, i.e. a TForm object. This object and all of the components it contains have RTTI informations. Delphi then just uses the functions of the TypInfo unit (also available in FPC) to read and write the properties of the components. When you save the form, the form object is serialized (streamed), and when you re-open the form, it creates an empty TForm object and loads the object state from the previously created stream.

- Sebastian

Mattias Gaertner wrote

I am glad to hear that LFM = DFM, since the format is simple and clear.

Not really, it's a big mess in fact, and might cause a lot of troubles with future platforms (especially 64 bit OSses). I personally recommend to use XML streaming instead, and I already started it, but it's not finished yet.

Please mail me your description of the format.

Do you still need it after the recent discussion...? No problem, but I would have to spend at least 2 minutes on locating the file on my harddisk :)

BTW, for what is your streaming code? Is it part of the free pascal compiler or is it for lazarus?

You will never see me coding anything for Lazarus ;) It's part of the FCL (which is in turn a basic component of the Free Pascal distribution), and the term 'streaming' refers to persistence of objects, i.e. the saving of the state of one or more objects into a stream and retrieving the state back from a stream.

[or in German to be really precise, sorry other folks: 'Streaming ist der Vorgang, wenn der Zustand von Objekten in eine Datei (einen Stream) gesichert wird, und zu einem sp�teren Zeitpunkt wieder hergestellt wird. Sozusagen das Laden und Speichern von Objekten.']

- Sebastian

Marc makes a good point. The object inspector should use the RTTI to set/get properties of controls not the DFM.

I'm not sure how much RTTI support exists currently in FPC so I can't help with those aspects. IS the RTTI code implemented in FPC already?

Shane

As Shane already said, LFM files are just DFM (Delphi Form) files. If you need the exact format, I can mail you a description I've used for myself for the Free Pascal streaming code.

- Sebastian

It is and it should be also in the FCL already.

I'm curious in how the DFM/LFM format is incompatible with a 64 bit OS (or 128 bit OS like on a Sony Play Station, ect.)? I guess this would be in reference to the binary DFM file format, which I'll admit will have some problems as you mention. What would a text-editor readable format of the DFM offer that would be counter to an OS or CPU which is greater than 32 bits?

If you want to write an object inspector, you don't need the DFM layout. You can make object inspector based upon the RTTI info.

The Object inspector needs the RTTI. This is a fact. But as far as I have seen: The RTTI can't store the values in the program on disk, can it?

Under Delphi changed values are stored in the DFM file and compiled in via the {$R *.DFM} directive. Which is a much better solution than to store it in the Form.Create method (see examples). It would be nice if lazarus would do it in a similar way. And main.pp shows some promises. But I didn't found any traces of LFM code in free pascal.

My question is now:
How will lazarus store the values of the forms on disk (LFM, perhaps like text based DFM) and how will these values get into the compiled program?

The format of LFM is not that relevant but I think it should be editable by a simple text editor (no binary format).

Mattias

+ From: Mattias Gaertner
+
+ >As Shane already said, LFM files are just DFM (Delphi Form) files. If
+ >you need the exact format, I can mail you a description I've used for
+ >myself for the Free Pascal streaming code.
+
+ I want to participate in writing the object inspector for lazarus
+ and looked up for documentation. The current lazarus code creates LFM
+ files which looks like DFM files, but the web page says: +
+ I am glad to hear that LFM = DFM, since the format is simple and clear.

+ Please mail me your description of the format.

Let me make some things clear. I've the feeling that we are heading in the wrong direction.

If you want to write an object inspector, you don't need the DFM layout. You can make object inspector based upon the RTTI info.

If you want to be able to design/layout forms and recreate them, you need to stream this info to a file (LFM). The format here is at that moment not the question.

If you want the LFM to be DFM compatible you should stream the info using the DFM streamer (if it exists, if not, and thats the only case, you need the DFM layout)

If you want the LFM in an XML format you should stream the info using the XML streamer.

Now back to your original question, if you want to create an object inspector, I would say GREAT, but you don't need the DFM layout.

+ BTW, for what is your streaming code? Is it part of the free
+ pascal compiler or is it for lazarus?

AFAIK part of FPC.

Marc

Hi all,

where can I find some information about the layout and the design of the LFM files?

Mattias

Hi

It's in the fcl. I made a little test a few months ago and works good (as far as i can see).

bye,

Stefan