|Delphi Clinic||C++Builder Gate||Training & Consultancy||Delphi Notes Weblog||Dr.Bob's Webshop|
Mixing C++Builder and Delphi code
In this paper, I will demonstrate that C++Builder can not only compile Delphi source code, but that the CodeGear RAD Studio with the C++Builder 2007 and Delphi 2007 for .NET identities combined can mix languages (one per source file) in C++(Builder) projects.
C++Builder 6 (and earlier)
The main difference between C++Builder up to version 6 and C++Builder 2006 is that the latter also consists of an IDE with not only C++(Builder) but also Delphi language capabilities. Although most people may know that C++Builder 6 can compile Delphi source code (like VCL components or Forms and their units), the Delphi units added to a C++Builder 6 project were always "read-only", as the C++Builder 6 designer is only able it generate C++ code (for new components and events). As a consequence, it was not really easy to do mixed-language development using Delphi and C++Builder. Prior to version 2006, that is...
With C++Builder 2006, the IDE contains the design-time knowledge to be able to work on Delphi Forms even if the current personality is C++. So as of C++Builder 2006, we can safely add Delphi units and code to C++Builder projects. There is one caveat: the C++(Builder) project can use the Delphi units, classes and code, but the Delphi units have no way of accessing or using the C++ code (as far as I can tell - if anyone knows of a trick, feel tree to let me know).
Since Delphi cannot compile C++ code (but the reverse is possible), this is also the reason why we can add Delphi units to a C++(Builder) project, but not the other way around.
Note that for C++Builder 2007, this technique is most likely only possible if you also have the Delphi 2007 for Win32 identity installed in your CodeGear RAD Studio. A stand-alone C++Builder 2007 can compile Delphi code, but will probably not have the Delphi designer. I write "probably", since I do not have a C++Builder 2007 installation (without Delphi 2007 for Win32 as well, that is). If someone has a C++Builder 2007 stand-alone installation, feel free to try to add a Delphi form to your C++Builder project and see if you can add a new component to it or create a new event handler (and thanks in advance for letting me know the outcome).
C++Builder and Delphi
To demonstrate this, let's create a C++Builder 2007 application that uses a Delphi Remote Data Module (to solve a little problem I've had recently - but which will be fixed in a future update of the CodeGear RAD Studio).
Unfortunately, the following will fail on Windows Vista.
The problem is related to the fact that the template files for the C++Builder Remote Data Module reside in the Objrepos\cpp directory, in which the current user has no "write" permission.
This can be fixed by giving the "write" permission to the Users group (i.e. the group with the user currently running C++Builder 2007).
However, just to show the ability of a C++Builder project using Delphi code (and being able to modify Delphi code in the IDE), let's use a Delphi Remote Data Module!
Delphi Remote Data Module
We can not directly add a Delphi Remote Data Module to a C++Builder project: the Object Repository will not show the Delphi Multitier category, and only the C++Builder Multitier category. We have to first create a "dummy" Delphi project, add a (Delphi) Remote Data Module to it, and then manually add that data module (and type library import unit) to the C++Builder project.
The steps are as follows:
Note that you should not yet add any datasets to the Delphi Remote Data Module - that will be done from C++Builder instead!
The Project Manager should now contain two projects, and the C++Builder project consists of both C++(Builder) and Delphi files:
[DCC Warning] DelphiWrapper_TLB.pas(58): W1025 Unsupported language feature: 'dispinterface'
Since this was presented as warning and no fatal error, I just continued my experiment with the Delphi Remote Data Module inside a C++Builder project.
This shows that we can modify Delphi forms, data modules and even source code (like events) inside C++Builder, which is nice to know and enables us more easily to (re)use existing code (or programmers) in projects.
The C++Builder project still compiles fine, as you will notice (if you decided to play along so far).
We can now run the DataSnapServerCPP application and register the Remote Data Module inside it.
Using a C++Builder Remote Data Module, the registration will be attempted automatically at program startup (this was changed for Delphi 2007, but not yet for C++Builder 2007).
Since we are now using a Delphi Remote Data Module, the registration will not be done automatically, but we have to run the DataSnap Server on the command-line, with the /regserver command-line argument. See my blog post for some methods of doing this with the administrator rights on Windows Vista.
After the Remote Data Module inside the DataSnap server has been registered, we can run the DataSnapServerCPP and make it wait for incoming client connections.
To complete the example, return to the Delphi wrapper application and remove the Remote Data Module and Type Library import unit from the project. Place a TDCOMConnection component on the Delphi form, and open up the ServerName property which will show the just registered Delphi Remote Data Module (note that the name is reported to be DelphiWrapper.DelphiRemoteDataModule, since this Remote Data Module was initially created as part of the DelphiWrapper application, and only later actually moved to the C++Builder application to be used).
We can now open the TClientDataSet, work with the data, etc., and there's no noticeable difference to notice that the C++Builder DataSnap server is using a Delphi Remote Data Module.
This experiment adds to my believe that the combination of Delphi and C++Builder is stronger then ever, and mixed language programming (starting with a C++Builder project) is easier than ever, too.