Communication between C++ and Delphi

Question

0.00/5 (No votes)

See more:

Hi, Let me try to explain my problem here.

I have a DLL, it is written in C++. It monitors all print objects for incoming print jobs (Through a Thread)and then fetch some information from print details. Upto here it is OK. Now I have to send this information to delphi project who loaded this C++ DLL.

I am really clueless how can I make this communication happen

Let the c++ code has following functionality:
Initialize or start monitoring print objects (starts thread)
if any print job comes, asome information is fetched
Now I have to send back this info to that Delphhi code who is waiting for it.

Let the Delphi code is like below:
[DELPHI CODE]
Load DLL;
Wait for message
Unload DLL

Can any one give me any overall all idea. No need to tell me the code but some mechanism is needed.

update:
Is use of share memory is that solution?
Thanks.

Posted 21-Mar-13 7:59am

iDebD

Updated 21-Mar-13 8:08am

v2

Add a Solution

3 solutions

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Matthew Faithfull · Accepted Answer · 2013-03-21T08:34:00

Solution 2

If you have the source to both parts, C++ and Delphi and you build both with C++ Builder/Rad Studio then you can call the C++ code from the Delphi and the other way around too.
In that case you could do what you want with a callback. You pass the address of a Delphi function into the C++ as a function pointer parameter. Then call the Delphi function using that pointer when the C++ has a message to send back.
It may sound complicated but it's a lot simpler than shared memory.
Your C++ Builder/Rad Studio should have samples for calling one kind of code from the other, add a little google research into C++ function pointers and you should be able to make it work.

Posted 21-Mar-13 8:34am

Matthew Faithfull

Comments

Espen Harlinn 21-Mar-13 16:11pm

5'ed! :-D

Matthew Faithfull 21-Mar-13 19:27pm

Thanks very much. COM would of course work equally well.

Sergey Alexandrovich Kryukov 21-Mar-13 20:18pm

Fair enough, my 5. COM should rather be considered absolute, but COM interfaces (especially implemented via IDL), and their implementations are compatible and can be used very well, to introduce OOP-style DLL import/export compatible with both languages. I did it the way it was compatible with Unix...
—SA

Maxim Kartavenkov 22-Mar-13 5:19am

Your solution just copy of mine, but there is require to have dll to be compiled in C++ Builder.

Matthew Faithfull 22-Mar-13 5:26am

No not a copy, I'm not suggesting shared memory just a normal DLL interface and yes both the C++ and the Delphi need to be build with the same calling conventions and name mangling scheme to ensure that a call interface will work. The easiest and best way to do this is build both with the same compiler suite so that you can be sure it can work. Otherwise you never know. Try calling a 5 parameter function in a DLL built with GCC from an EXE built with MSVC even though are C++ on Windows and you'll likely see what I mean. Bang, crunch, splat :-(

Maxim Kartavenkov 22-Mar-13 5:34am

I'm not suggested shared memory, I even post the whole code how it should looks. And it not require C++ Builder, it not require to be in same calling conversion bcs delphi allows to specify calling conversion without problems. What for necessary here the GCC and MSVC? here is the delphi. but I'm sure if you proper bind you dll interface you will never get your issue with GCC and MSVC.

Matthew Faithfull 22-Mar-13 5:41am

Sorry, I read the wrong solution as yours. I read his question but not your solution which was posted long after mine and looks very complete and in fact does what I was refering to. You're using 'C' calling convention to get over the potential mangling issues which is fine but not always viable if for example you want to export classes. I'll vote up your solution.

Maxim Kartavenkov 22-Mar-13 5:54am

in case of exporting classes - then yes different compilers cause an issue, but that can be easy solved to make C functions export wrap around classes, actually that is mostly done in particular API just the classes pointers are output as a HANDLE for example.

Espen Harlinn · Accepted Answer · 2013-03-21T08:36:00

Solution 3

Assuming you're using Visual C++, you could use COM, here is a pretty nice tutorial: A Beginner Tutorial for Writing Simple COM/ATL DLL For VS2012[^]

Delphi works pretty well with COM, so accessing the COM object should be quite easy.

Best regards
Espen Harlinn

Posted 21-Mar-13 8:36am

Espen Harlinn

Comments

Maciej Los 21-Mar-13 15:56pm

+5!

Espen Harlinn 21-Mar-13 16:13pm

Thank you, Maciej :-D

Sergey Alexandrovich Kryukov 21-Mar-13 20:20pm

My 5, but I don't know what exactly do you mean by COM. Please see my comment to Solution 2. I think the best way of using COM is when you avoid using windows COM API (and contaminating the registry) at all. COM used to be an OOP patch to non-OOP OS...
—SA

Espen Harlinn 21-Mar-13 20:50pm

Delphi relies on correct component registration, which IMHO isn't a bad thing ...

Many people consider COM and CORBA to be obsolete, but in my view w3c based technologies has a long way to go before they match either of them.

While neither of the technologies are dead, they require a fair level of skill. Implementing someting similar to a WCF service is trivial when you use either of them, it's when you expose objects, that has among other things a lifetime, that many developers had trouble keeping up.

COM is a fundamental part of Windows, and MS keeps adding new APIs' based on COM to the operating system.

The biggest problem with COM and the registry is 'lazy' system administrators that can't be bothered to either use the installation programs provided with a solution or actually figure out how this actually works. The problem is that many sysadmins tries to modify how the installation is supposed to work - there probably aren't any 'sane' reasons for this, in 99 out of 100 scenarios they should just do a full installation of the software, and install software and patches in the order of their release date. It's when they don't follow this very simple procedure that they run into problems, and instead of taking the resposibility for their own shortcommings they blame the technology.

Sergey Alexandrovich Kryukov 21-Mar-13 20:57pm

Well, I understand all that, many good points here. It all depends on what do you consider "obsolete". Morally obsolete. Windows is obsolete, in this sense. It's a dead end. Windows 8 is especially sad, due to certain revival of COM, in particular...
Anyway, direct use of exported functions (perhaps with COM interfaces as I tried to explain in my comments) for language interop (also obsolete), is the clearer way. How to explain that? Due to less multiplication of evil in the world... :-)
—SA

pasztorpisti 2-Apr-13 5:06am

"+5", a brave fight for simplicity. I've always used dlls with exported _stdcall methods for interp between languages regardless of the direction of communication. Easy implementation, problem free use. A corrupted com registry and the error messages popping up when your program can't start are hard to explain for a user (pointing the direction can also be difficult), and can cause headaches even for developers to find out what is the real problem.

Sergey Alexandrovich Kryukov 2-Apr-13 8:44am

Thank you for understanding. In the past, I developed a whole technology, and the small part of it was multiplatform use COM interfaces; which was possible through not using any COM-related OS component. A DLL always exported a top-level function returning implementation of a top-level object implementing a top-level interface which is used to get all other objects...
C++ class import/export was not an option, because the system was also multilanguage...
—SA

pasztorpisti 2-Apr-13 10:05am

That's exactly the same way as I'm using DLLs, actually I wrote a tip about that because IMO many people misunderstand and abuse DLL interfaces. A single exported function that returns a pointer to a high level object or struct as you said is far enough to get the job done. Easy to implement/use on any platforms and avoids the painful dll interface maintenance.

Sergey Alexandrovich Kryukov 2-Apr-13 10:44am

Great.
—SA

Espen Harlinn 2-Apr-13 11:37am

>> IMO many people misunderstand and abuse DLL interfaces.
I take this to mean that if you follow your own advice, you expect thatmost "programmers" will have a bit of trouble using your solution. Working with COM, Corba and DCE is usually a great way to implement cross language, and even cross process/machine solutions in a typesafe manner.

pasztorpisti 2-Apr-13 13:33pm

Don't misunderstand, it was absolutely not about COM, Corba and similar solutions, those have their own place. Just mentioned that many people tend to put a lot of exported dll functions into the dll interface (including name-mangled c++ methods) and I think is harder to maintain and more messy than exporting just one function when you create the DLL project. Exporting more functions is obvious for first as most dll tutorials encourage to do so, but that doesn't mean its a good way to go.

Espen Harlinn 2-Apr-13 16:22pm

I'm looking at the question, which says a bit about OP's probable skill level and try to adjust my answer accordingly. He proably don't know much about COM, but the tutorial should suffice, and he is left with something he may use with delphi, .Net, Perl etc. COM is a fundamental part of Windows that I think every developer should be familiar with. My hope was that I provided an answer that also added something of value to OPs' general knowledge of programming.

pasztorpisti 2-Apr-13 17:20pm

That's absolutely true - you provided a perfectly valid option to solve the problem and knowing about com is essential. On the other handt COM isn't one of the easiest topics for a beginner and in this case it could be shooting at sparrows with a cannon... :-)

Espen Harlinn 2-Apr-13 17:23pm

True enough, which I guess is why I 5'ed Matthew Faithfulls' answer about just as soon as he posted it ;)

pasztorpisti 3-Apr-13 5:09am

You got your 5 too. :-) One of the most important aspects of development is being able to choose between your options but in order to be able to do so you have to actually know the alternatives!

Espen Harlinn 3-Apr-13 12:39pm

I think we can well agree on that ;)

Albert Holguin 22-Mar-13 0:03am

+5... that's what COM's for... or was for... or whatever... :)

Maxim Kartavenkov 22-Mar-13 5:26am

If he doing DLL from scratch the COM will be fine and fair enought to make whole system, but if he already have dll and to modify it for COM along with whole application will be very painfull and requres a lot of time, so simple callback it is much easy. Regarding interfaces in object pascal - delphi without problem allows to import typelibrary - so no necessary to writing interfaces in pascal in case you have proper typelibrary in your COM.

Espen Harlinn 24-Mar-13 13:24pm

Wrapping an existing DLL is usually trivial, and the result is that you have someting that not only works well with Delphi, it works with Perl, Visual Basic < 7.0, .Net and a plethora of other development environments ...

Maxim Kartavenkov 24-Mar-13 14:07pm

Sure that will works as it is an automation, but integrating simple callback is much easy and faster to implement and integrate, plus the COM plumbing will require additional knowledge of COM itself implementing COM objects in C++, probably ATL and it classes and their architecture connection points, dispinterfaces and so on. Compare to implementing callback it just require add the one function to set callback and make to call callback routine from existing code without much modify existing C++ or delphi code.

iDebD · Accepted Answer · 2013-04-01T22:29:00

C++

C++ DLL: "MyDll.dll"
/////////////////////////////////////////////////////
typedef HRESULT (CALLBACK * CALLBACKPROC)(DWORD wEvent,LONG_PTR arg,PVOID pParam);
/////////////////////////////////////////////////////
CALLBACKPROC g_pCallback = NULL;
LPVOID g_pCallbackParam = NULL;
/////////////////////////////////////////////////////
EXTERN_C VOID __declspec(dllexport) WINAPIV SetCallback(CALLBACKPROC _proc,LPVOID pParam)
{
g_pCallback = _proc;
g_pCallbackParam = pParam;
}
/////////////////////////////////////////////////////
#define SOMEDLLMETHOD_EVENT_ID 0x01
/////////////////////////////////////////////////////
EXTERN_C VOID __declspec(dllexport) WINAPIV SomeDllMethod()
{
if (g_pCallback) g_pCallback(SOMEDLLMETHOD_EVENT_ID,(LONG_PTR)"some argument",g_pCallbackParam);
}
/////////////////////////////////////////////////////
// Delphi wrapper with dynamic DLL linkage:
/////////////////////////////////////////////////////
type
TDllWrapper = class
protected
FOnDllEvent: TNotifyEvent;
m_hDll: HMODULE;
protected
function OnCallbackEvent(wEvent:DWORD;arg:Pointer):HRESULT; virtual;
public
procedure CallSomeDllMethod();
public
constructor Create;
destructor Destroy;
published
property OnDllEvent: TNotifyEvent read FOnDllEvent write FOnDllEvent;
end;
 
type
TCALLBACKPROC = function(wEvent:DWORD;arg:Pointer;pParam:Pointer):HRESULT stdcall;
type
TSetCallbackFunc = procedure(_proc:TCALLBACKPROC;pParam:Pointer) cdecl;
 
const SOMEDLLMETHOD_EVENT_ID = $01;
 
function CallbackProc(wEvent:DWORD;arg:Pointer;pParam:Pointer):HRESULT stdcall;
begin
result := 0;
if (pParam <> nil) then result := TDllWrapper(pParam).OnCallbackEvent(wEvent,arg);
end;

constructor TDllWrapper.Create;
var
fnSetCallback:TSetCallbackFunc;
begin
inherited Create;
m_hDll := LoadLibrary('MyDll.dll');
fnSetCallback := GetProcAddress(m_hDll,'SetCallback');
fnSetCallback(CallbackProc,self);
end;
 
destructor TDllWrapper.Destroy;
var
fnSetCallback:TSetCallbackFunc;
begin
fnSetCallback := GetProcAddress(m_hDll,'SetCallback');
fnSetCallback(nil,nil);
FreeLibrary(m_hDll);
inherited Destroy;
end;
 
function TDllWrapper.OnCallbackEvent(wEvent:DWORD;arg:Pointer):HRESULT;
begin
result := 0;
if (wEvent = SOMEDLLMETHOD_EVENT_ID) then
begin
if Assigned(FOnDllEvent) then FOnDllEvent(self);
end;
end;

procedure TDllWrapper.CallSomeDllMethod();
var
fnSomeDllMethod:procedure() cdecl;
begin
fnSomeDllMethod := GetProcAddress(m_hDll,'SomeDllMethod');
fnSomeDllMethod();
end;
/////////////////////////////////////////////////////
// Example of usage:
/////////////////////////////////////////////////////
type
TMainForm = class(TForm)
m_MyDll:TDllWrapper;
procedure OnDllEventCallback(Sender: TObject);
procedure FormCreate(Sender: TObject);
procedure FormClose(Sender: TObject; var Action: TCloseAction);

end;
 
procedure TMainForm.OnDllEventCallback(Sender: TObject);
begin
OutputDebugString('Our callback event called');
end;
 
procedure TMainForm.FormCreate(Sender: TObject);
begin
m_MyDll:= TDllWrapper.Create;
m_MyDll.OnDllEvent := OnDllEventCallback;
m_MyDll.CallSomeDllMethod;
end;
 
procedure TMainForm.FormClose(Sender: TObject; var Action: TCloseAction);
begin
m_MyDll.Free;
end;

[edit]code block added[/edit]