[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 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.

Daniël