Hi,

Some users suggested, that components should be stored in pascal source (optionally).
IMO there is one big advantage:
Storing in source means no need for the streaming system at runtime, which means no need for published properties/methods at runtime, which would help smart linking to reduce the size of the executable. I have not tested, but it should be quite a bit for the LCL.

The LCL and IDE uses the TWriter of the FCL, which has the ability to write to various formats. There is already a rudimentary pascal writer in lazarus/examples/pascalstream/componentstreampas.pas.

There are some issues left that must be solved before it can be used in the IDE:
1. TCollection needs a typecast to the item class
2. forward dependencies
3. the 'with' can create conflicts
4. what to do with DefineProperties?
5. a reader

Point 1 should be solvable with a typecast.
Point 2 can be solved by first creating all components and then assigning the properties.
Point 3 can be solved by using fully qualified identifiers. Point 4 is the real problem. How to store TStrings.Data or TBitmap.Data?

You are welcome to solve the open issues. I will then help to use the reader/writer in the IDE.

Mattias

Op 2011-01-17 00:45, Mattias Gaertner het geskryf:

4. what to do with DefineProperties?

What is that? What is it used for? I could find any help on that.

Point 4 is the real problem. How to store TStrings.Data or TBitmap.Data?

I had a look at the TStrings class definition in FPC 2.4.3. TStrings doesn't have a Data property or a Data field, so what do you mean by TStrings.Data?

Regards,
- Graeme -

This is streamed through 'DefineProperties', a protected call to write custom data to the stream.

There is no way to solve this for Pascal streams, as the 'Data' does not necessarily exist as a settable property, and any kind of data can be written.

In particular, the ability to position the cursor anywhere in the stream during DefineProperties also will IMHO prove impossible to do.

Michael.

It would be sufficient if the solution is good enough for classes in the FCL and LCL. They write some simple properties and a stream.

Either by providing a simple Filer or by registering for each such class an addon.

Mattias

On Mon, Jan 17, 2011 at 1:45 AM, Mattias Gaertner <

When the topic appears some time ago, I experimented creating procedure converting dfm text form into delphi code. Point 4 was a real challenge.

For TStrings it was just assuming if token is '(' then it's TStrings (possible not always true, but there are so many TStrings inside *CL and user's codebase this is almost safe to assume)

For binary data (token '{') was a more complex thing. As a self-explaining example, the following code from TImage dfm. I made it in Delphi, but surprisingly (or not depending on the person) Lazarus accepted the converted approach without any problem :) As long as I remember, in Delphi data from TTreeview was always successfully converted.

****************** begin of fragment *************************

object Image1: TImage
Left = 184
Top = 16
Width = 49
Height = 33
Picture.Data = {
07544269746D617076010000424D760100000000000036000000280000000A00 .....}
end

was converted to

...

  TReaderHack = class(TReader);

....

  Image1.Left := 184;
  Image1.Top := 16;
  Image1.Width := 49;
  Image1.Height := 33;
  DataString:=
#7'TBitm'+'apv'#1#0#0'BM'+'v'#1#0#0#0#0#0#0'6'#0#0#0'('#0#0#0+#10#0+#0#0+...;
  Insert(#4'Data'+Chr(Ord(vaBinary)) + #130#1#0#0, DataString, 1);
  Stream:=TStringStream.Create(DataString);
  try
    Reader:=TReaderHack.Create(Stream, 1024);
    try
      Reader.ReadProperty(Image1.Picture);
    finally
    Reader.Free;
    end;
  finally
    Stream.Free;
  end;

****************** end of fragment *************************

btw, since Lazarus is oss, the hack for TReader here that is needed only to call protected method, can be solved other way.

Max Vlasov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110117/abb8e18c/attachment.html>

Ok. The pascal streamer is a driver level, so it knows the type and does not need to guess here.

Sounds good.

How did you solve TOpenDialog.Left/Top?

Mattias

On Mon, Jan 17, 2011 at 1:38 PM, Mattias Gaertner <

It's ok, I just was confused by the fact that particular token leads to particular 'Add(...' calls, looked like a too-specific solution, but maybe VCL always had something special about TStrings, I can't recall

How did you solve TOpenDialog.Left/Top?

I remember I noticed those but postponed and looks like didn't solve. As long as I remember those exist for every TComponent that is not TControl, CMIIW. The excuse was that if the feature itself is for run-time, it's not big deal not to read design-time positions for them. But for consistency sure it would be better to solve .

Max
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110117/bdac4da8/attachment.html>