Linux, Kylix, CLX, EJB, and CBuilder | C++Builder 5 Developers Guide

Linux, Kylix, CLX, EJB, and C++Builder

C++Builder now offers several features to support cross-platform development activities ”you can develop on Windows and deploy to Linux (a variant of the popular Unix operating system) or develop on Linux and deploy to Windows.

C++Builder is primarily focused on Windows development. But any program you produce in C++Builder, so long as it only uses the CLX components , can be compiled on Linux using Borland's Kylix (currently at version 3). So, your company can have copies of C++Builder on Windows, use those for creating and testing programs, and then recompile those programs on one or more Linux computers, using Kylix, for deployment.

What's the catch? You need to limit your use of the rapid application development features of C++Builder to controls that are part of the Borland CLX cross-platform component set. Fortunately, this isn't much of a burden because most of the standard UI, data, and Web components are part of CLX.

CLX Overview

Deep details about CLX can be found in Sams Kylix Developer's Guide , but here are the highlights:

CLX is not VCL and VCL is not CLX, but both are rooted at TComponent .
CLX wraps the Qt class library, a cross-platform library from TrollTech, which works on both Windows and Linux.
Why not do this with the VCL? Simply because the VCL exposes certain Windows-based data structures that need to be hidden for cross-platform applications.
Unlike VCL, CLX completely hides the idea of user interface messages. Instead, it provides a comprehensive set of event handlers for anything you might have used messages for. There is no message loop, no message dispatcher, and no capability to redirect messages with BEGIN_MESSAGE_MAP / END_MESSAGE_MAP .
Qt is a least common denominator class library ”it surfaces the features common to Windows and Linux. It is up to Borland and third-party developers to reimplement those features that might be specific to each platform, or even beyond the platforms.
There's no CLX tab on the component palette. How do you know which components are CLX? Well, first of all, all the dbExpress components are, whereas the ADO and BDE components aren't. So, if you want to access databases on both platforms, dbExpress is the way to go. As for user interfaces, data aware user interfaces are done with conventional TDB controls such as TDBGrid and TDBEdit . Dialogs such as TOpenDialog are part of CLX. None of the ActiveX or OLE controls are usable within CLX. The FastNet controls are also not usable for cross-platform Internet work: the Internet components you can use in CLX are those on the WebSnap, Internet, and Indy tabs.

Your ultimate resource for cross-platform components is the help file that comes with C++Builder ”look at the section "CLX Component Reference" for a complete and up-to-date list.

Cross-Platform Help System Integration

Cross-platform systems need to be able to provide cross-platform help. CLX (and VCL) both provide access to help viewers without locking you into a platform ”help viewers are provided by classes that implement the ICustomHelpViewer interface; for Windows, this is TWinHelpViewer . On Linux, it might well be another class provided by your help viewer vendor or implemented by you to provided that capability.

An application must register itself with the global HelpManager so that its help requests can be passed to the correct viewer; this is done automatically by TApplication . And, of course, the help viewers/help systems must register themselves and the help they provide with the Help Manager so they can get and handle the requests.

The biggest problem is the help context, which the help viewer uses to determine what help the user wants displayed. Most Linux help viewers will not understand the numeric help contexts that are common in WinHelp files. This implies that you will need to hide the nature of your help contexts and use numeric contexts under Windows, and non-numeric contexts under Linux (using a conditional compilation to control what is generated).

Simplified IDL, IIOP, and EJB

The Borland Enterprise Server (and its ancestor , Borland Application Server), implemented communication between Java programs and Enterprise Java Beans (EJB) using IIOP (Internet Inter-ORB Protocol), a standard devised for communication between CORBA (Common Object Request Broker Architecture) objects.

Why does this matter to a C++ programmer? Well, there are more and more EJB-style interfaces being made available by various software package vendors , and, perhaps, even by a programmer down the hall from you. It would be nice if you could easily leverage their facilities from your C++Builder programs, and you might even be able to avoid bringing yet another language (Java) into your shop.

The process is conceptually simple: If you use JBuilder, create the IDL for your EJB through the IDE for JBuilder (right-click the project, pick Options, then from the dialog pick Build, and click Generate IDL in the Java2IDL Settings; the next compile will generate the IDL you need).

If you are not using JBuilder, or don't have the Java source, create the IDL with the Borland Enterprise Server Visibroker java2idl command-line utility.

Either method produces a file that describes the interface to the EJB in language-independent terms.

In C++Builder, use File, New, CORBA Client and provide the name of the IDL file as requested by the wizard.

At this point you now have a client that can call the EJB. All you need to do is to have the EJB in an appropriate application server (one which, like Borland Enterprise Server, implements EJB and application server communication with IIOP).

Top