Can LCL be used from other programming languages?

[LazaruX]

I am curious, can LCL be "called" from other languages? (e.g. C++?)

[marcov]

Hacks are always possible, but not in a straightforward way.

It is like how C++ QT has to be flattened by qtpas. You need to cater for the change in object model and for the use of types the other language doesn't have (templates, ansistring etc)

[LazaruX]

Actually I meant calling the methods like in a DLL...But thanks for the reply




Btw you should put some sugar on that oliebol

[marcov]

Actually I meant calling the methods like in a DLL...But thanks for the reply

Yes, me too :-)  QT is also in a DLL, but to access this C++ code  from FPC, we must flatten it to plain procedural code (qtpas.dll), and then rebuild it OO in the QT widgetset of Lazarus.

IOW the otherway around (C++ code using Object Pascal code) would need the same treatment, since C++ can't directly call Pascal methods, and doesn't know all Pascal types.

[Fred vS]

I am curious, can LCL be "called" from other languages? (e.g. C++?)

Hum, other languages may use fpGUIlib (library version of fpGUI who is 100 % pure fpc library) 
https://github.com/fredvs/fpGUIlib

[Leledumbo]

I am curious, can LCL be "called" from other languages? (e.g. C++?)

There you go. The project is a stub with TApplication, TForm and TButton only, but it works. No one seems interested enough to continue its development so it stays as a stub. LCL is quite HUGE to port and if nobody uses the bindings, the effort will be useless.

[marcov]

It probably would have to be autogenerated to be of any use.

[TurboRascal]

BTW, I was wondering about the possibility of using LCL and FPC classes in general from Delphi... Is it possible to export/import classes without flattening?

[skalogryz]

...sigh... Interfaces?

[TurboRascal]

Thanks, I'll look into it. But, since I'm pretty much dumb about interfaces, I'm sure to trip up on something soon, if nothing else some memory management issue...

Any tips&hints to get me going?

[skalogryz]

Any tips&hints to get me going?

Sure, do exactly what you don't want to do! - flat the interface.
Do the plugin first.
Make sure it works (without mem leaks and other issues).

Once "flat" works, you can study interfaces and do the same plugin with interfaces.

[marcov]

One of the reasons is that interfaces are usually only an escape when designed in from the start, i.e. for new class hierarchies, not for already existing ones.

Moreover, the Delphi way relies on widestring being an automatable type over all borders, something that is windows specific.

[TurboRascal]

Thanks, so it seems to me that maybe flattening and rebuilding the class in Delphi the same way as I would for C++ is maybe the easiest way. For the simplest needs I'd say it's easiest to create objects in the lib and make them do all the work, while only passing them input variables from the host and providing procedure calls telling them to do the job.

[marcov]

Yes, and memory management must remain separated (so no automated types, and the RTL that is used to create an object must be used to free it).

There are exceptions to those rules, but in general it is wise to start with the above philosophy.

If it is windows only, it is probably better to turn both sides into COM Objects.