[fpc-devel] FPC dynamic libraries

Daniël Mantione daniel.mantione at freepascal.org
Thu Feb 8 14:35:30 CET 2007

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 extremely 
> > > simple and basic statements like
> > > 
> > > If (MyObject is TComponent) then
> > >   XYZ
> > > 
> > > will fail, even though MyObject is a TComponent, because the VMT of the 
> > > MyObject TComponent parent resides in the library, and the VMT of TComponent
> > > used in the If statement is inside Lazarus, causing the statement to fail, 
> > > even though it should be true. When using packages, the statement will 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.


More information about the fpc-devel mailing list