Delphi Clinic

C++Builder Gate

Training & Consultancy

Delphi Notes Weblog

Dr.Bob's Webshop

Borland C++Builder lost+found #15 See Also:  C++Builder Papers and Columns

Living Apart Together
It seems to me that since I am working with C++Builder 5 and Delphi 5 I regularly have te reiterate old stuff I used to write. I also notice while working with both development environments that they become more and more integrated. It does not look that way, but it is certainly the case.

Introduction
I left you in lost+found 10 with a way to call back from a C++ DLL into a Delphi executable. I also told you in lost+found 7 how to debug such a DLL in C++Builder using the setting for the host application. Well, things have changed a bit.

Debugging DLLs
In fact, I was debugging a little test application created with Delphi 5 that called an entrypoint in a DLL built with C++Builder. What actually happenen was that I only pressed the 'Jump Into' key one time too many. I expected to see the CPU window, but instead was shown the C++ sourcefile instead. This aroused my suspicion a bit. I subsequently tried inspecting a few variables. What happened was that I got a C++Builder Inspector while working in Delphi! Once back in Delphi, the Inspector was the regular Delphi one again. This can only mean one thing. Either I have a very special setup in which a couple of lucky accidents happened, or this functionality was built into Delphi from the beginning. Either way, it is a sign that the debugging symbol format of both Delphi 5 and C++Builder 5 are so similar that debugging C++ in Delphi is a possibility and I suspect that the reverse is also true. [Since C++Builder can already compile Pascal code, I'd say that's indeed the case - Bob]

Method Callbacks
The other thing I discovered is that it is possible to call a method in a class for an object. Does the term 'closure' mean anything to you? The term surfaces when you read up on creating your own events and event handlers. It actually is a pair of pointers. The first one points to the address of the method in the class, the second one points to the object for which the method must be executed. It should now be clear to you why closures are used in event handling. What happens is that if you create a handler for some type of event, the event is associated with the closure that points to the OnXXX method in the particular object that handles that event. I was inventing a callback scheme again. The problem was to pass a possibly large number of strings. The classic approach is to pass a buffer to a DLL and let the DLL fill that in. The drawback is that you must enlarge the buffer if it is not large enough, and the resulting code on the calling side is quite complicated. What if I could pass a callback to such a function in the backend that is called from there once for every string to be passed to the Delphi part? Have a look at the C++ part:

  typedef void __stdcall
    (*StringElementCallbackProcType)(const char* str);

  __declspec(dllexport) long __stdcall SendNamesToProc(StringElementCallbackProcType cb)
  {
    long result = BACKEND_ERROR;
    try
    {
      //  Iterate over the vector of strings and call back
      //  for each string in the vector
      vector sl = GetNameStrings();
      for (vector::const_iterator i = sl.begin();
        i != sl.end();
        ++i)
      {
        cb((*i).c_str());  // !!Callback to procedure!!
      }
      result = BACKEND_OK;
    }
    catch (exception& ex)
    {
      SendExceptionNotification(ex);
    }
    return result;
  }

  type
    StringElementCallbackProcType = procedure(astr: PChar); stdcall;

  function SendNamesToProc(cb: StringElementCallbackProcType): Integer; stdcall;
           external thedll name 'SendNamesToProc';

However, in C++ it is possible to call methods for a certain object, and why wouldn't that be the same for Delphi? Actually, this can be accomplished. It took some intense reading in the help file, but once I was on the track of closures, the solution was near. The Delphi way of declaring a method pointer is as follows:

  type
    StringElementCallbackObjectType = procedure(astr: PChar) of object; stdcall;

  typedef void __stdcall
    (__closure *StringElementCallbackObjectType)(const char* str);

  __declspec(dllexport) long __stdcall SendNamesToObject(StringElementCallbackObjectType cb)
  {
    long result = BACKEND_ERROR;
    try
    {
      //  Iterate over the vector of strings and call back
      //  for each string in the vector
      vector sl = GetNameStrings();
      for (vector::const_iterator i = sl.begin();
        i != sl.end();
        ++i)
      {
        cb((*i).c_str());// !!Callback to object method!!
      }
      result = BACKEND_OK;
    }
    catch (exception& ex)
    {
      SendExceptionNotification(ex);
    }
    return result;
  }

  type
    TMainForm = class(TForm)
      ListBoxNames: TListBox;
      procedure FormShow(Sender: TObject);
      procedure AddName(name: PChar); stdcall;
    end;

  function SendNamesToObject(cb: StringElementCallbackObjectType): Integer; stdcall;
           external thedll name 'SendNamesToObject';

  ...

  procedure TMainForm.FormShow(Sender: TObject);
  begin
     SendNamesToObject(MainForm.AddName);
  end;

  procedure TMainForm.AddName(name: PChar); stdcall;
  begin
    ListBoxNames.Items.Add(name);
  end;