[fpc-devel] FPC dynamic libraries

[Daniël Mantione]

Op Thu, 8 Feb 2007, schreef Michael Van Canneyt:

> > > Secondly, there are serious problems with this approach which make it=
 unusable
> > > for an IDE like Lazarus.
> > > =

> > > Assume I get a component instance from the plugin (MyObject), then ex=
tremely =

> > > simple and basic statements like
> > > =

> > > If (MyObject is TComponent) then
> > >   XYZ
> > > =

> > > will fail, even though MyObject is a TComponent, because the VMT of t=
he =

> > > MyObject TComponent parent resides in the library, and the VMT of TCo=
mponent
> > > used in the If statement is inside Lazarus, causing the statement to =
fail, =

> > > even though it should be true. When using packages, the statement wil=
l function
> > > correctly.
> > =

> > I was talking a binary API, and that automatically disallows sending =

> > classes through the API, because you want to prevent that an internal =

> > change breaks your external API. Simply design the API in a proper way.
> =

> You can't, for Lazarus. You need the classes, that's what you need the
> plugins for in the first place: to install additional components on the =

> component palette. They must descend from the TComponent which is in
> the IDE.
> =

> There is no way around it.

Yes, there is, we should not forget we have a facility in the language =

to solve this problem: interfaces. Both components in the IDE as in the =

plugin can implement the same interface, event though they have different =

VMT layouts.

So, a component that you place in the component palette implements some =

kind of "palette" interface, providing the IDE with the communications it =

needs to work with the component.

Dani=EBl