Hi fpc-team,

I want to add datamoduls to lazarus. Borland added TDataModul to classes.pp. Probably this is not necessary. Should I add it to the lcl or should I send a patch for the fcl?

Does anyone know good reasons to put it into classes.pp?

Mattias Gaertner

Does anyone know good reasons to put it into classes.pp?

classes.pp would be much better; I personally have some stuff which is currently under development, which already has to use some hacks to get an equivalent behaviour...

- Sebastian

Personally, I don't understand why it should be in classes at all except maybe for some action stuff, but if Delphi puts it there, then I guess we'll have to do it too for compatibility's sake.

Michael.

Personally, I don't understand why it should be in classes at all except maybe for some action stuff, but if Delphi puts it there, then I guess we'll have to do it too for compatibility's sake.

TDataModule is a non-visual class, just a container for components (as you know anyway). So I think it's quite logical to put it into classes.pp

BTW, we have another problem: InitInheritedComponent. Currently it is not implemented in the FCL; fpGUI and fpWeb have their own implementation, but we urgently need a common (and portable) implementation for this function. Perhaps we should add a callback function which is responsible for reading components from a stream. (see fpgui.pp for an example, what has to be done. Basically: What extensions should the files have, and where should they be located. fpGUI actually uses the folders unit; perhaps we should finally add this to the FCL?)

- Sebastian

In that case the name 'TDataModule' is not really representative. TComponentModule might be a better name. And then create a TDataModule descendent.

As far as I can see, we need a function that returns a stream which contains the component data. All the rest can be handled in a 'global' way; Only the instancing of the stream is specific to the kind of streaming used.

For lazarus, this would probably be a memory stream which is instantiated from the lazarus resources. For fpgui, this would be a file stream which points to the .dfm file. A combined approach is possible, of course.

So, basically we need a callback which returns the appropriate stream to instantiate the component ? Do I undertand this correct ?

Michael.

In that case the name 'TDataModule' is not really representative. TComponentModule might be a better name. And then create a TDataModule descendent.

And what should be the difference between these two classes?

No, we need exactly this. I propose to add a callback similar to FindGlobalComponent etc.

type
   TReadComponentCallback = function(const AClassName: String; AInstance:
     TComponent): Boolean;
var
   ReadComponent: TReadComponentCallback;

(just a proposal)

And, you didn't answer this yet :) : Should we move the folders unit to the FCL or not? I think it will be quite useful for different things

- Sebastian

I would remove the Width/Height/Top/Left streaming code from TComponentModule; Also, web stuff and so doesn't necessarily need TDataModule, it just needs 'components'.

The reason I propose not this is that there is still quite some general-purpose code in InitInheritedComponent, which should not be handled by the callback IMO. After studying it a bit, I decided that the system specific boils down to creating the right stream; All the rest is general-purpose (globalloading list handling etc.).

And, you didn't answer this yet :) : Should we move the folders unit to the FCL or not? I think it will be quite useful for different things

I'm sorry, I didn't catch this ? Where is this unit ? I haven't found it in any directory on my harddisk ??

Michael.

I would remove the Width/Height/Top/Left streaming code from TComponentModule; Also, web stuff and so doesn't necessarily need TDataModule, it just needs 'components'.

I think TDataModule only adds Left and Top, which are properties of all components nevertheless (see DesignInfo)

I meant ReadComponent as a callback which is used by InitInheritedComponent, as a replacement for InternalReadComponentRes

Ooops. It should have been part of fpGUI, but I just checked and noticed that I didn't add it to CVS yet. :-/
We talked about this quite some time ago... I think we'll continue this discussion via private mail

- Sebastian

This has been fixed in libgdb 5.1+

The libgdb is only tested linked statically in the FP IDE. The IDE of 1.0.6 contains a fixed libgdb.

Hi,
I noticed that gdb does not release file handle after use. I think it can be actual in FP IDE also. There is no problems under win9x, because there is a lower files protection. But under winnt (2000) this file can not be removed (or linked).
Tested with gdb 4.18.b1 and libgdb 5.0.

You can try this (must be under winnt):

gbdpasw file [program.exe] run file

del [program.exe]
It deletes program only after gdbpasw close.

> Hi, > I noticed that gdb does not release file handle after use. I think it

can

> be > actual in FP IDE also. There is no problems under win9x, because there

is

I created dll with libgdb 5.1, but can't load it. When i try to do this program stops responding, maybe you have any idea why can it be so?