is there any way to use delphi component in lazarus? i.e. mabye a DLL?

[snorkel]

Ok, I have this Delphi project from a few years ago that uses all stock components except for virtual string tree and trichview.
I can easily port it except for the trichview which is used in a couple of forms.
Would it be possible to host the forms that use trichview in a dll and then use the DLL from the new Lazarus version of the app?

I really want to kick delphi to the curb completely...    I asked the trichview author about a port to Lazarus and they do have it  in their plans eventually.  Could be years before they port it as they want to do a activeX version first.

[Mike.Cornflake]

I don't know the answer to your question - but you will be able use the ActiveX Port, at least on Windows, when that's finished.

Oh wait, I do know one answer to your question :-)   Use Delphi, create an ActiveX wrapper around the component, use the ActiveX wrapper in your Lazarus app :-)  (and who knows, if you get the interface right, when the ActiveX port does get complete, you might not need that many changes...)

http://wiki.lazarus.freepascal.org/LazActiveX

Mind you, I don't know the practicalities of this.  Been a *LONG* time since I created an ActiveX control in Delphi.  At the time there were hurdles and hoops galore to run around, but that was back when ActiveX was still new...

[vfclists]

I asked a similar question recently http://forum.lazarus.freepascal.org/index.php/topic,25831.

@taazz has some pointers on how to go about, which in summary involves writing access functions and exporting them to a dll, using stdcall and cdecl options.

[taazz]

well the think is that most likely the delphi components will work as they are in lazarus but they will not be cross platform. There are some very noticeable reasons for the component not to work in lazarus wich are divided in to 3 main categories

1) Unicode support : delphi 2009 and newer have different string handling than lazarus.
2) Windows message handling : lazarus does not forward all the windows messages because it doesn't support all of them on all platforms.
3) generics and the newer language constructs.

there are no generic guidelines you can follow to make sure that the component will be able to compile in lazarus but if you manage to categorize the problems in one of the above categories you are half way there to port the component and probably 75% of the way to get a solution in this forums.

[mangakissa]

1) Unicode support : delphi 2009 and newer have different string handling than lazarus.

Yes, but if the using string in D2009+ will be the same to FPC. The compiler handles this unicode situation, not the code itself.
The only problem would be the function charinset().

[taazz]

1) Unicode support : delphi 2009 and newer have different string handling than lazarus.

Yes, but if the using string in D2009+ will be the same to FPC. The compiler handles this unicode situation, not the code itself.
The only problem would be the function charinset().

I have no idea whats going on in 2.7.1 compiler version but in 2.6.4 it is not handled automatically from the compiler the compiler in fact assumes ANSI character are in the string.

The LCL's choice to use the ANSI code page UTF8 to support unicode seems to work so far but they will need to change to unicodestring as well in windows when fpc releases the unicode support (which is similar to what delphi has today).