How to connect delphi to .net objects

There are some ways to call managed code from unmanaged code. The easiest way is to expose a COM API from the .NET code. Take a look at [link text][1]

[1]: http://msdn.microsoft.com/en-us/library/ms973872.aspx An Overview of Managed/Unmanaged Code Interoperability

I've been testing AtoZed's "CrossTalk" product to directly call .Net from Delphi7 for one of our products. (The calls are to a .Net 4 wrapper around the Atalasoft DotNet imaging library to extract and retrieve some end-user financial application form TIFF images from an uploaded multi-page PDF).

There are some limitations (such a issues handling some .Net collections), but overall CrossTalk seems to be working so far. (I still have to test for resource leaks, etc. before making a buy/no-buy decision). Any limitations I've hit so far, I've been able to deal with by modifying the .Net wrapper around the vendor's interface to reformat problem objects (like the generic collections) into something more easily consumed on the Delphi side.

If you're stuck with older versions of Delphi like D7, you'll also have to work around syntax limitations you wouldn't see with newer Delphi versions like D2006/D2007 and above. The worst one I saw so far was that .Net Class-level static functions, properties, and procedures are translated with the "static" keyword; which D7 doesn't understand but which later versions of Delphi do. To get around that when your ultimate target is 3rd-party code, you'll again have to modify a custom .Net wrapper around the actual target to take that issue out of the equation.

Now that my evaluation has gone beyond feature set into performance, the biggest issue I've seen so far is a small performance hit per call; something on the order of 8 hundredths of a msec. per call under a profiler (which slows things down) on a WinXP VM. If you're making a relatively small number of calls across the boundary per use, this is probably not an issue. But when I tested moving a 1MB .Net byte array across the boundary from .Net to Delphi and then using a transformed ByteArray.Get_Item indexed access within a Delphi For loop to access each byte of the .Net array to copy it into a corresponding Delphi byte array for use with Delphi GUI controls, that extra overhead caused a significant problem. That small 0.08 msec. overhead per call times 1 million "For" Loop accesses across the .Net-Delphi boundary added up to almost 8 full seconds. (That particular feature test ran far faster when using COM to pass the byte array).

It was actually far faster to have the Delphi code call the transformed .Net System.Drawing.Image's "Save" (ToFile) method and have a Delphi TImage "LoadFromFile" than it was to do the 1M accesses necessary to move the byte array one element at a time but all within memory.

I'm working this issue with AtoZed support to see if there is a way around this and will post the outcome after they've had a fair amount of time to address it. The 1MB byte array was the body of a scanned form image.

The great thing and the reason I want to work with them to fix this issue is that your Delphi code can create, consume, and dispose of native .Net objects instead of having to make do with whatever can be marshaled across COM boundaries. (I've seen complaints on the web about resource leaks using COM for such cross-tool interactions because of issues getting the objects disposed on the Net side. Perhaps that was due to poor code, but it's something to think about.) You don't have to deal with using the SafeArrays that are used for marshalling arrays across COM and separate interfaces for each custom business object. CrossTalk also gets around having to deal with having to mark all the .Net assemblies ComVisible, having to install the .Net COM assemblies into the GAC if you can't control where they are located relative to your Delphi code, etc.

With CrossTalk, you browse in each assembly from which you need to consume classes or methods. Don't forget you'll also need to explicitly browse in and bring in classes from system assemblies like mscorlib, system, system.drawing, etc.

If your use case doesn't call across the boundary large numbers of times, it's probably worth at least a look. I did find another similar product on the web at http://www.managed-vcl.com, but it's a bit harder to get contact with the author, so I never did complete evaluating that approach.

I cannot find how to comment yet I know others will read your comments. Thanks for the MSDN web page I could not find it as MSDN library as it’s very large. Now if I go off the target or get side tracked please correct me.

In Delphi we have ‘project/import type library’ to import many things from scripts, ActiveX to nearly all MS products, MS has ever made for windows. Delphi 4 supports File/New to bring a dialog box up and the ActiveX tab contains ‘COM object Wizard’ for multiple objects. Effectively we have interfaces and objects in Delphi that create objects from MS type library’s. Personally I have never used it yet Delphi is rich in these methods. From the web pages you have given me MS says a pour connection arrives from importing a ‘.net type library’ into Delphi. What is suggested from MSDN as a more robust way in Delphi is to incorporate a DotNet.pas file to link to the .Net frame work as a com connection, as that has been on my heart all along. My idea has gone as far as rebuilding windows.pas from the ground up. Or is their better way yet to get a robust .net and lowers instruction count to access objects and methods.
I also found in Delphi:- IFormDesigner. And I have questions like who allocates memory to the .net object when it’s called. And how is a method connected to the object. I’m not sure were to start or end yet because none of this is documented on the internet to my knowledge to get me started. So it’s like diving into the dark to some extent. At the same time getting hold of some of these sub objects like IUnknown, IDispatch, ISupportErrorInfo, IMarshal and reserved words like dispinterface is quite a learning curve too. Some of these sub objects are not documented in Delphi. I understand HRESULT is for error checking purposes and GetLastWin32Error is a carry on from com objects GetLastError. IntPtr is new to me that I guess is something like PChar in Delphi. Sometimes referring to Delphi’s automated objects is a little complex to look at in the way I need to think. But when you are learning you dart all over the place with pour direction. I mite need to use them and I question of safe ways to test a new object with out crashing the Delphi editor all the time with little error support in Delphi.