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
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
