[lazarus] Multiplatform, the story goes on

Nicolas Aragon nico at clubdelphi.com
Sat Jul 3 11:57:47 EDT 1999


Hello,

>> When you write a new widget, you must decide if it will be generally
>> available or just for the lib you're using.
>yes, of course. But I see one big disadvantage in your approach: It
>won't be possible to derive an existing (and fully implemented) widget
>class. 

I can't see why.

>s said before, in KCL there's this TSHTextEdit widget.
>TSHTextEdit is generally available, but it is derived from TScrollBox,
>which has to be implemented differently for each target.

I don't fully understand what's the problem. Surely because I don't
know these classes. But one thing is clear: implementation is
completely separated from interface, in fact this is the main purpose
of my idea.

>> Of course the solution is easy with multiple inheritance:
>This would be possible; but I think the solution we found in KCL is
>simple enough...

If you mean using defines, it can do the trick. But not all.
OK. Wait to see the code and you'll judge by yourself.

>> >> I have it. And it's very simple: component libraries are objects.
>> >Can I do something like:
>> >  TScrollBox.Create
>> >within my application? I don't think so.
>> Yes, you can.
>I've thought about all this dynlinking stuff (see other postings), and I
>think it is possible if all methods are external. 

Are you suggesting to make a class whose methods are implemented in
some other place?

>VMTs and RTTI tables. But I don't know what will happen if you want to
>derive an external class, as the VMTs and RTTI stuff can't be declared
>as external - the code FPC generates would have to call the inherited
>constructor and to use the information it has set up. 

I think you are missing the main point: both sides includes an uses to
the abstract ancestor. It's enough to make the objects compatible.

Moreover, it works. Delphi uses this technique in several places since
version 2. 

greetings

  Nico






More information about the Lazarus mailing list