Hi,

is it possible to use a TForm inside a TForm?

Imagine a program consisting of a frame and some plug-ins. The plug-ins should get designed using lazarus, each having it own form. When loaded those forms would be embedded into the main applications form as a frame, e.g. each on a tab of a notebook or similar.

If it is not possible, what alternative ways of designing something like that should I consider?

TIA,
Marc

It is possible. Check the Lazarus Forum for a procedure i posted a while back that embeds a form inside a TWinControl by reparenting the form controls and keeping the form itself in memory so local (in form class) variables will still work.

However currently it is not possible to use LCL with a DLL. I tried it, in order to create a control from a DLL that will be used and it failed (crashes, etc). I don't know enough about LCL internals to say why though.

Testing showed it does not work, if done like this:

procedure TForm1.FormCreate(Sender: TObject);
var
  f2: TForm;
begin
  f2 := TForm2.Create(Panel2);
  f2.show;
end;

the secomd form is shown seperately and managed by the window manager. Using MDI didn't do it either.

If it is not possible, what alternative ways of designing something like that should I consider?

The last possibilities I see are streaming parts of the form myself or using the dock manager thingy. Can someone explain how docking would be done (or point me to the docs), please?

Marc

Am Samstag, den 17.05.2008, 16:34 +0300 schrieb
Kostafile:////home/marc/.evolution/cache/tmp/drag-n-drop-CzHRMD/Nachrichten_von_Lazaruss Michalopoulos:

It is possible. Check the Lazarus Forum for a procedure i posted a while back that embeds a form inside a TWinControl by reparenting the form controls and keeping the form itself in memory so local (in form class) variables will still work.

I'll do that, thanks.

However currently it is not possible to use LCL with a DLL. I tried it, in order to create a control from a DLL that will be used and it failed (crashes, etc). I don't know enough about LCL internals to say why though.

Hmm, that makes the complete idea of plugins obolete somehow ...

Did you link your program against the dll or was the loading done dynamically? (On *nix there is dlopen/dlclose and dlsym for dynamically loading libraries, I don't know the windows equivalent of those)

Many thanks,
Marc

Note:
Nesting TForm or TFrame inside a TForm is possible. Just set the 'Parent' property and when embedding a form, make sure to set the BorderStyle to bsNone.
The IDE designer does not yet allow to _nest_ forms in the designer (I'm working on that, but I guess it will take a month before it becomes ready and stable). Of course you can design forms. _Designing_ frames is still experimental.

Putting LCL controls into a dynamic linked library is only possible with more or less dirty tricks. This is independent of nesting forms.

Mattias

The parameter to the Create constructor is the 'Owner', it does not set the 'Parent'. Use instead:

  f2 := TForm2.Create(Panel2);
  f2.Parent:=Panel2;
  f2.Visible:=true;

Here is a start:
http://wiki.lazarus.freepascal.org/Docking

Mattias

  procedure TForm1.FormCreate(Sender: TObject);
  var
    f2: TForm;
  begin
    f2 := TForm2.Create(Panel2);
    f2.Parent := Panel2;
    f2.show;
  end;

(mumble) ... I think I have to re-learn a lot of things.

It does work perfectly and one can see it too if the position is set
accordingly (f2.left/top := 0). :)

Wonderful, thank you.

Marc

Mattias Gaertner wrote

Putting LCL controls into a dynamic linked library is only possible with more or less dirty tricks. This is independent of nesting forms.

What are these tricks?

I read about shared libs in the wiki reagrding RTL/VMT duplication and having a shared memory manager. A quick test switching program and form-contaning dll to cmem did not help.

My goal is to have a core programm and some additional parts delivered separately. Compiling the program for every permutation of combinations is not quite usable if the count of extras goes up.

Marc

Exactly controlling the state of the RTL. Either to be exactly the same in the dynlib and the mainprogram, at least for the cases that matter.

I read about shared libs in the wiki reagrding RTL/VMT duplication and having a shared memory manager. A quick test switching program and form-contaning dll to cmem did not help.

That is correct, those are the most important ones. There is no end user safe way to my knowledge, just limited experiments of people that knew what they were doing. (or were lucky)

My goal is to have a core programm and some additional parts delivered separately. Compiling the program for every permutation of combinations is not quite usable if the count of extras goes up.

Packages is the only long term way. Unless your interface between the DLL and the program can be really limited and rigid. Then you might have luck the manual way.

So no way to go for production software (at least for me ;).

I don't understand, do you say, packages are dynamically loadable? I thought of them as statically linkable organizational containers.

If a user has installed the basic program, can I send him a package that can be loaded at statup extending the program?

Marc

Only by loadlibrary calls. (which must then be in the startup), and of course the interface must be known. But in general yes.

Keep in mind that designtime packages are implemented using library packages inside Delphi. Delphi isn't recompiled for them :_)

The interface will be small and I'm free to define that doesn't solve the problems using LCL in libraries, does it?

The wiki article about library packages showed that someone actually succeded in compiling the RTl to a dynlib, that may be woth a test (combined with loadlibrary).

Keep in mind that designtime packages are implemented using library packages inside Delphi. Delphi isn't recompiled for them :_)

Interesting, I stopped using Delphi shortly after version 3 was out. ;)

Marc

Note:
The term 'package' has many meanings.
A 'lazarus package' is a set of files/directories with some extras like compiler settings, output directory, i18n directory. It can be used to compile ppus, or to compile a static or dynamic library. A 'delphi package' is almost always a set of units with a dll (named bpl) as target. It uses some compiler magic to allow sharing classes/types and RTL between dynamic linked libraries. FPC fully supports static libraries and 'normal' dynamic libs and platform independently. But is does not yet provide the compiler magic to share classes/types between dynamic libs. So, you can use the LCL as static lib, but not as dynamic lib (at least not comfortable). When it will, lazarus packages can be compiled to dynamic libs. It is possible to do the magic manually, but it is complicated.

Yes, it is possible with loadlibrary. But you also must call the initialization/finalization sections manually of *all* used units in the correct order.

Keep in mind, that all dynamic libs must fit exactly. This means every package must be compiled and provided for every supported version. In case of Delphi this means a a new version every 1-3 years. In case of lazarus/fpc it means several versions a year multiplied by all supported platforms. And all the users that use snapshots or svn must compile the packages anyway.
So dynamic libs are least useful for developers, which is why there is not much done yet. Probably someone must provide a bounty.

Mattias

That part is clearly described in the wiki.

I see. Thanks for being verbose.

Okay, so I can only reject that idea. My knowledge of such internals is too small to take that risk.

Not very attractive regarding lazarus itself ...

Probably someone must provide a bounty.

Maybe next time. Even if I would, the time frame for waiting on this feature and the risk with new implementations would both be too big.

I'll have to try to convince anybody involved that "change concept" is better than "use java" then. :(

Thanks for making things clear,
Marc