$ startdelphi &
    $ startbcb &

The Integrated Development Environment (IDE)

The previous section provided a brief outlook of the Kylix platform. This section will provide an overview of the different component parts that comprise the Kylix IDE, in order to familiarize the readers with this RAD tool. For those of you who come from the C++ (or any other) traditional programming style, initially, Kylix will be a shock. As one would expect, Kylix provides drag-and-drop style programming, particularly with respect to the GUI-based applications. In a typical application, components from the component palette are dragged using the mouse and dropped onto the form in the visual form designer; then the properties of the components may be set/reset in the Object Inspector. The CLX component framework is event-based, and the interactions of the user and the system with the application (or its components) are controlled through a set of predesigned events. The application’s response to the events is coded by the developer in the respective event handlers. If an event’s event handler is not implemented (or not coded) by the developer, the specific owner of that event (component or application) ignores when that event is fired, or takes the default action as designed for that event. In this section, an effort will be made to describe the different component windows accessible from within the IDE and their use. However, it should be noted that the menus, toolbars, and other component parts of the IDE discussed in this book refer to the Enterprise Edition of Kylix 3, and some of them may not be available in other editions. More details can be obtained by contacting the Borland Software Corporation directly.

Menus and Toolbars

As can be seen from the earlier figure, the main menu of the IDE consists of vast menu options such as the File menu, Edit menu, Search menu, View menu, Project menu, Run menu, Component menu, Tools menu, Window menu, and Help menu. The entire functionality of the Kylix platform can be accessed through the menu items, and some of the most commonly used features are accessible through the toolbars. The File menu offers the options needed to work with the files—such as opening, closing and saving the file, saving the file with a different name, and so on. The Edit menu contains options needed to work with the contents of the files and components placed on the form, such as selecting a block of text, copying or cutting the selected block of text to the clipboard, pasting the text from the clipboard to a specified location, aligning the components on a form, and so on. The Search menu provides options used to locate a specific text block in the entire file (supports case-sensitive and case-insensitive search), replace the text block with new text, and so on. The View menu offers options to bring hidden or closed windows to the front and display those windows that are usually not displayed, such as the Project Manager window, to-do-list window, component list window, component alignment palette, and so on. The Project menu’s options are used when working with the application projects; they allow the user to create new projects, add external files to a project, compile the individual source programs, build the entire project, and add the project to the repository maintained by the IDE. The Run menu contains options relevant to running the application, which include debugging options such as those to start the debugging process, trace into the code, add and remove the breakpoints, and so on. The Component menu options are used when working with components and packages, such as installing and removing components and packages and configuring the Component palette. The Tools menu options let us define the editor options, environment options (including the project level options and compiler and linker options), debugger options, and so on. In addition, external tools (supplied by Borland or a third-party vendor) can also be configured to be available from this menu and be invoked. As an example, Borland’s XML Mapper tool is available as an option in this menu and is used when working with XML files while developing distributed applications. The ‘Configure Tools’ menu option invokes a dialog that will drive the users through the process of registering an external application to be invoked from this menu. The Window menu presents the list of all the windows (including those belonging to the IDE and those belonging to the application) currently displayed; however, some of them may not be visible to the user if they are covered by other windows. To bring a window to focus, just select that window from the list. This is particularly useful when some smaller windows are hidden behind larger windows. Finally, the Help menu lists all the online help documents shipped and installed with Kylix.

As mentioned earlier, some of the most frequently used menu options are provided through toolbars. By clicking the appropriate buttons located within the toolbars, the specific feature is executed. The different toolbars available in the Kylix 3 IDE are the Standard toolbar, View toolbar, Debug toolbar, and Desktop toolbar, as shown in Figures 6.2, 6.3, 6.4, and 6.5.

When a mouse pointer is placed over a button in a toolbar, a small hint window is displayed indicating what the button is for. It should be noted that the buttons located in these toolbars are selected from different menu options—with a view to providing fast access to some of the most frequently used items—and do not contain all the features supported by the menus. For specific items not located in the toolbars, the appropriate menu should be searched. There is also another small toolbar with only one button to invoke the main Help screen, and it is by default located next to the Standard toolbar. All the toolbars can be undocked from their respective locations and docked again. The main window displaying the main menu also acts as a docking station for the toolbars and the component palette. Docking (and undocking) is the process by which child windows can be freely attached to (and detached from) a parent window, which acts as the docking station.

Component Palette

The Component palette is typically docked to the main window but can be undocked if desired. As discussed before, the Kylix platform is bundled with the CLX component library, and the components are organized in different tabbed pages on the component palette. Normally when a package is installed through the Package Installation dialog, which is invoked by selecting the Component ® Install Packages menu item, the components bundled in the package are installed in the specific pages of the Component palette, as explained in the package description. If desired, the organization of these components can be changed through the ‘Palette Properties’ dialog, which is invoked by selecting the Component ® Configure Tools menu item from the main menu. Through this dialog, you can rename, add, remove, or reorder pages and components within a specific page. However, it should be remembered that when the specific package (containing components and pages that have been reorganized) is reinstalled or updated to a newer version, your customized reorganization of the Component palette might be lost, or replaced with the default settings described in the package. Figure 6.6 shows what the default Component palette looks like in an Enterprise Edition of Kylix 3.

In this subsection, an attempt is made to introduce the component groups provided with the Kylix 3 Enterprise Edition, leaving detailed discussion to later chapters on specific programming topics. As mentioned earlier, the components within the Component palette are arranged in pages, where each of the pages represents a particular group of components. The ‘Standard’ page contains components that are most commonly used widget controls, such as frame, main menu, memo, edit, label, button, checkbox, radio button, list box, combo box and panel, and so on. The ‘Additional’ page contains additional widget controls such as bit button, speed button, string grid, draw grid, image, scroll box, splitter, timer, and more. The ‘Common Controls’ page contains widget controls such as tab control, page control, image list, track bar, progress bar, tree view, list view, tool bar, text viewer, text browser, spin edit, icon view, and so on. The ‘System’ page contains components that let you display the directories and file structure in graphical view. These include directory view, file list view, file icon view, file edit, and so on. These controls are similar to the Windows shell controls and provide low-level access for developing custom-built dialogs to access the Linux file system. The ‘Dialogs’ page houses the prebuilt components required for the most commonly used functions such as opening and saving files, choosing fonts and colors, and finding and replacing text in a document. The three pages ‘dbExpress’, ‘Data Access’, and ‘Data Controls’ together provide a way to access the data from the underlying database and display to the user in a presentable way, as explained here. The components located in the ‘dbExpress’ page provide the vital link to the database by establishing a connection between the application and the database and enabling the application to retrieve data from a table or perform other database-related tasks such as executing dynamic queries and stored procedures. The ‘Data Access’ page contains components that act as conduits between the ‘dbExpress’ components and the user interface elements and provide seamless access to the database either directly or through a provider. These include data source, client dataset, dataset provider, and XML-based components. The ‘Data Controls’ page contains the user interface components that are used for displaying data directly from the database tables; it includes the data grid, row-level navigator, and other edit fields to handle the display features necessitated by the different data types. Together, all the components belonging to these three pages described here play a vital role in developing two-tier and three-tier applications. However, developing multitier applications also involves the use of other components, such as those that are wrapped around the networking and CORBA (or similar) technologies. The components located in the ‘Internet’ page of the Component palette are useful in developing Web applications using Borland’s WebBroker technology, based on the CGI (Common Gateway Interface) framework. These include the Web dispatcher, which dispatches the HTTP requests to appropriate action items in the application and a group of content producer components such as page producer, dataset page table producer, dataset query producer, TCP/IP server and client sockets, UDP socket, XML document, and so on. Although the WebBroker technology certainly is helpful in building small-to-medium Web applications, the WebSnap architecture (which is built on the framework laid out by WebBroker) provides advanced features such as the ability to host multiple-page modules, server-side scripting using the most popular JavaScript, the adapter components that interface between the server-side scripts and the application program written in Delphi or C++, and so on. The ‘WebSnap’ page in the Component palette houses a number of components that are used in building Web applications using these advanced features. There are built-in adapter components to perform a number of tasks automatically. The ‘Web Services’ page provides components to enable publishing Web service applications and work with the SOAP protocol. The ‘Indy’ (or Internet Direct) components are developed by an open source project group and are made available by Borland along with its Kylix 3 platform. The ‘Indy’ project provides more than 100 components for developing applications with almost any kind of network protocol published as of today, and these components are divided into five groups, with each group being placed in a separate page in the Component palette.

As noticed from this discussion, it is clear that the Kylix 3 platform is capable of supporting the RAD method of application development for any type of business need, using the powerful Object Pascal and C++ languages.

Form Designer and Code Editor

The form designer is an integrated part of the IDE and is visible only through the application main form and the steps we follow in designing the form with the required components. Typically, applications are created by selecting the appropriate application type from the ‘New Items’ dialog, which is invoked either by selecting the File ® New ® Other menu option or by clicking the ‘New Items’ button located in the ‘Standard’ toolbar. The default ‘New Items’ dialog looks similar to Figure 6.7. However, some third-party vendors might also add new pages or items to this dialog when their packages are installed.

The majority of the applications supported by Kylix 3 include a main form, although the type of the main form may be different depending on the application type. Therefore, when an application type is selected from the ‘New Items’ dialog, the IDE automatically displays the main form and the code editor window showing the skeleton code for the main form. A component is a perfect example of an object in the object-oriented programming paradigm. The whole idea of the RAD process centers around the concept of creating object instances by clicking on the specific component in the Component palette and dropping it onto the form. This is more like a click-and-drop operation rather than drag-and-drop. Every time a click-and-drop operation is performed, an instance (or an object) of the clicked component is created and dropped onto the form. Components are characterized by their properties and methods, and they interact with the user and the system through the robust event-driven architecture. When components are dropped onto the form during design time, their state can be stored to persistent storage, as every time the form is saved all the components contained in the form are also saved with their state information. The published properties of the components can be accessed through the Object Inspector, and their ownership by other components or by the main form can be seen through the Object TreeView. However, depending on the nature of the components, some of their properties are restricted only to runtime access, and the component writers make sure that such properties are not published. For many Linux programmers using C, C++, and Object Pascal, the Kylix IDE certainly provides a break, due to its RAD features.

Object Inspector and Object TreeView

As mentioned earlier, The Object Inspector is a special window provided in the Kylix IDE to inspect and set the object’s state at any time. This window may be closed if you do not like to use it; however, to use the form designer and visual application development concepts, it is necessary to use the Object Inspector window because that is where the properties of objects are set. Typically, the Object Inspector looks like Figure 6.8.

There are two tab pages within this window; one is for displaying the properties and the other is for events. The ‘Properties’ page displays two columns: the first column identifies the name of the property, and the second column displays the current value of that property. The properties displayed in the Object Inspector window always correspond to the most recently selected component on the form. If the property is modifiable, users are permitted to change the value of the property. Whenever the value of a property is changed, some preliminary validation is performed (as programmed by the component writer) on the new value of the property. If the new value fails the validation process, an exception is raised and the corresponding message is displayed in a message window. The new value of the property is saved as part of the component’s state when the form is saved. The ‘Events’ page displays two columns, with the first column showing the available events for that component and the second column showing the name of the actual event handler method that will respond when that event occurs. Depending on the nature of the component, the component writers publish only the relevant events for which the component will be able to respond through the event handlers. An event handler is a method that will be invoked if the programmer implements that event handler. If the programmer does not implement a specific event handler (because usually the component’s default response is enough) then the component responds with the default behavior as designed in the component. For example, the button component has an event called the ‘OnClick’ event. If the programmer implements the ‘OnClick’ event handler method for the specific button, then whenever the application user clicks on that button, this event handler is invoked automatically because Kylix event architecture makes the component respond to the events through the event handlers. If the application developer does not implement that event handler, then the component responds with the default behavior. More details on these topics are discussed later in the chapter. At this time, it is sufficient to understand that by double-clicking on the white space in the second column, an empty event handler method is automatically created with the appropriate method signature, and the name of this method appears in the second column against the specific event (which was previously filled with no value). If we double-click in the second column for an event that has already been implemented, then the code editor is displayed with the cursor being positioned at that event handler method, for each access of the programmer. It should be remembered that all the empty event handlers will be automatically removed when the program is saved. This is a feature of the IDE (and not a bug) to ensure that the program looks clean without empty event handlers.

The Object TreeView displays the list of all the components placed on a form in a tree view structure, and is a useful window to quickly locate and select components, which are otherwise hidden behind other components. Components in the CLX framework are related to some higher level (container) components through the concept of ownership, which is discussed in a later section in this chapter. The Object TreeView displays this type of container-owned relationship among the components. It also permits users to move the components owned by one container to another container, using the mouse pointer. Figure 6.9 displays an Object TreeView window in its default view, when an application is created.

Project Manager and Project Files

A Kylix project typically identifies an application, all the files related to the application are combined together into a project, and the project definition is stored in one or more project files. In today’s application development scenario, the process of using projects to manage complex applications is predominantly employed by many application development frameworks and IDEs—and Kylix is no exception. The Project Manager is an integrated part of the IDE, and as we work with our project, the Project Manager also works in the background by updating and saving the project files accordingly. The Project Manager window is the best place to check all the files included in the project. The window is invoked by selecting the View ® Project Manager option from the main menu. The Project Manager window looks similar to Figure 6.10.

Within the Project Manager window, we can add external files and resources to the project, remove one or more existing files from the project, or change the project compile and link options by choosing the appropriate options from the pop up menu invoked by placing the cursor on the specific project and clicking the right mouse button. When new forms are created through the ‘New Items’ dialog, they are automatically added to the currently active project; you do not have to explicitly add them. Also, when image files are used in setting the image-related properties (the ‘glyph’ property most of the time), the image is automatically added as a resource to the form and is saved along with the form file. Therefore, it is not necessary to add images explicitly. Normally when a form is included in more than one project, in the first project it is added through the ‘New Items’ dialog, and in the second project it is added through the Project Manager. Intermediate object files (created through another project) may also be added through the Project Manager. We can also combine more than one project into a Project Group, thus enabling ourselves to access all related projects at once. For Delphi projects, the main project file is identified by the project name and the .dpr extension, and contains the main program of the application; additional units are added when new forms (or units without a form) are added to the project. Other project-related settings (such as the compiler and linker options) are saved in additional project files (having extensions .conf and .kof). For C++ projects, the main project file is identified by the project name and .bpr extension, and contains the complete project definition as a XML file. Unlike the Delphi project file, the C++ main program unit (containing the main() function) is not saved in the .bpr project file, rather an additional file is created with the same name as the project and having .cpp file extension. Two files are created for every new form added to the project: the .xfm file stores the form definition in text format while the program unit file is stored with the .pas extension in Delphi projects and with the .cpp extension in C++ projects.

Code Editing and Compiling

In addition to creating the project-related files, the IDE also creates the skeleton code necessary for a Delphi or C++ program. In addition, as discussed before, the empty event handlers are generated by double-clicking the left mouse button for the specific event in the Object Inspector’s ‘Events’ tab page. For the events to appear in the Object Inspector, they should be published as properties. However, if we do not want the event handler to be assigned during design time, we can manually set the event handler during runtime by assigning any appropriate method (having the same method signature as required by the event) to the event. The code editor is the window where the program source code is displayed and edited. The code editor supports a number of features that improve the productivity of the developers. These include code templates, code completion and navigation, parameter completion and hints, and tool tip symbol insight, are collectively known as code insight, and are explained here in detail.

A code template is a piece of code that is typically used repeatedly. The IDE contains standard templates for many programming constructs such as an array declaration, a case statement, a for loop, a function declaration, and so on. The code template window is invoked by pressing the CTRL+J key combination; the cursor should be placed at the location where the code template should be placed in the program. When the code template window is invoked, a list of names of currently defined code templates is displayed as shown in Figure 6.11. The list may be scrolled up and down using the arrow keys. Next, the required code template is selected. When a specific code template is selected, the code defined in the template is placed where the cursor is positioned, as shown in Figure 6.12.

Although the IDE comes with default code templates, the developers are not limited to only this list; rather, they can create any piece of code as a code template. To define new code templates or edit the existing ones, the Editor Properties dialog must be invoked by selecting the Tools ® Editor Options option from the main menu. In the displayed window, select the tab page titled ‘Code Insight’. The window looks similar to Figure 6.13. In this window, the list of existing code templates is displayed by their names, and three buttons are also provided to add, edit, and delete code templates along with an embedded code edit window, apart from other options.

Code completion is a feature by which the IDE automatically displays the properties, methods, and events of objects in a small popup list, as and when the object name is entered followed by the dot . or ® depending on whether it is a Delphi program or a C++ program, respectively. From the displayed list of items, the required property or method or event can be selected. Figure 6.14 shows the popup list of items relevant to the object. Because an object can only be accessed through its public and published properties, methods, and events, the code completion window lists only those items. However, if the object is not in the current scope or if the object is typed erroneously, then the code completion window does not appear. This feature may be used as an indication to check whether or not the object name was entered properly.

The other feature, code parameter hints, is very similar to the code completion, as it displays the method signature (parameter types and their sequence) for all the overloaded methods with the same name, as we complete typing the method name and are about to start entering the parameters. This way, we do not have to remember the method signatures while making calls to these methods. As we keep entering the parameters, the methods whose signatures do not match with the already entered parameters are dropped from the list automatically. There is another feature known as the tool tip symbol insight, which displays an identifier’s declaration information when the mouse cursor passes over the identifier name. In addition to these features, the ‘Editor Properties’ dialog can be used to customize other options to suit the preferences of the developer.

The most important step in application development is compiling the individual program units into object files and linking them all together to generate the final executable file. One of the aspects of traditional Linux development is writing the make files for the make utility. For experienced developers, this is not a difficult task. However, for those just learning Linux programming, it can be very frustrating because it is not sufficient just to know the make file syntax rules; rather, some expertise is needed to attain a level of comfort. Windows programmers, in particular, are used to working with tools that are more GUI-oriented and therefore are usually less patient with the command-line tools. The Kylix IDE is certainly a major boon for all such GUI-favored programmers because it is not necessary for them to write make files any more. The Kylix project files are used by the inherent compiler and linker for all the necessary settings to produce the desired output. Any changes to these settings can be easily made through the Project Options dialog and the Environment Options dialog, which are shown in Figure 6.15 and Figure 6.16, respectively.

In the figure showing the Project Options dialog, a number of tab pages can be noticed. Each of these pages is used to set different options. In the figure, the compiler options page is displayed. Another frequently used page in this dialog is the one on which the output directory names (along with other directory names) can be specified in order to save the output of compilation and linking steps. Similarly, the Environment Options dialog also contains a number of tab pages, each for a different type of options. The figure displays the Environment Variables page, which resembles a similar page on the Windows operating system. In this page, we can see all the environment variables set for the current user’s session, and we are allowed to make changes to these settings. However, any changes made in this page are only limited to use by Kylix and do not affect the user’s environment variables as seen by other applications. Kylix uses a common terminology applicable to both Delphi and C++ programs. For this reason, a C++ program is called a unit, the tradition that has been followed since the inception of Delphi. Similarly, the member functions of CLX objects are also called synonymously as methods, even though these objects are developed (or used) in C++ programs.

The individual unit files are compiled by selecting the Project ® Compile Unit menu option or by pressing the shortcut key combination CTRL+F9. The individual unit-level compilation is similar to creating object files for individual programs in the traditional make process using the make utility. After all the individual unit files are compiled successfully to produce their respective object files, the next step is to link these files, producing the final executable program. This is performed by selecting the Project ® Make <project name> option or the Project ® Build <project name> option from the main menu. As specified here, the actual project name is shown in the menu choice. There is a difference between the two options. The ‘Make <project name>’ option will not attempt to recompile individual unit files if any of the source programs did not change since last time it was compiled. It simply performs the link edit step of a traditional make process. If any of the source files changed after it was compiled last, then this option will recompile all such program unit files. In addition, if none of the source files and the project file changed since the last time the application was built, even the line edit step is not performed when this option is selected. In a way, this option performs need-based compile and link edit processing. On the other hand, when the ‘Build <project name>’ option is selected, all the unit files are recompiled, even though the respective source programs did not change after the last time they were compiled, and then the link edit step is performed. Therefore, this option may be considered as performing forced compile and link edit processing. Earlier, it was discussed that more than one project can be grouped together as a project group. The Project ® Make All Projects and the Project ® Build All Projects options perform the make and build tasks on all the projects in the project group currently opened.

When a Delphi unit file is compiled, the corresponding object file is saved with the .dcu extension, which means delphi compiled unit. On the other hand, the object file created when a C++ program is compiled will have the .o file extension, as most of the readers would expect. If the application is an executable program, then the final executable file is named similar to the main project name without any extension. The final executable file is assigned execute permission in addition to the standard default permission settings set by the ‘umask’ setting in the user’s login profile file. The Kylix CLX component library is delivered as a set of shared libraries having .so extension. These libraries are installed in the Kylix bin directory, which is /usr/local/kylix3/bin directory by default. When we build an application in Kylix, we are certainly accessing the code built into these shared libraries. This means the linker has to link the application with these shared libraries. There are two ways this can be done. In the first scenario, we can tell the linker to include code from the shared libraries into our application, so that our application becomes a standalone executable (or another shared library, depending on the application type). This is done by unchecking the ‘Build with Runtime Packages’ option in the ‘Packages’ page of the ‘Project Options’ dialog. However, the price we pay for this feature is that the final executable file usually becomes large. In the second scenario, we can tell the linker not to include code from the shared libraries, rather just add the reference to the shared libraries in our executable. This process creates smaller executable files, but our application is dependent on the shared libraries supplied by Borland, and while deploying the application, the relevant Kylix shared libraries also should be deployed. This is done by checking the ‘Build with Runtime Packages’ option.

When our application is dependent on the runtime shared libraries (or packages), it is important that the directory location where these files are located should be specified in the LD_LIBRARY_PATH environment variable in the user’s login profile. Without this setting, we cannot execute the application from the command prompt. This environment variable is used by the shell to locate the shared object libraries at run time, while executing any executable binary file. From within the IDE, an application can be run through the Run ® Run menu option, or by pressing the F9 key. When this option is selected, the IDE makes sure that it runs the latest version of the program, which means that if there are any changes to any of the source files, it recompiles, link edits, and then runs the application from the IDE.

The Project ® Edit Option Source option in Kylix C++ IDE is worth mentioning at this point. When this option is selected, it displays the project definition, including all the configuration options as a single XML file. The data displayed in the code editor is read from the project’s .bpr file, which is only specific to the C++ IDE. This feature is not available to the Delphi IDE. Even though the contents are easily understandable, we do not suggest that you directly update them, because the IDE maintains it. The project options should always be changed through the different dialogs discussed earlier.

Object Repository

The object repository is a place in the IDE where larger reusable code modules can be stored for later use. While the code templates are helpful in storing program source code snippets, the object repository can store forms, frames, dialogs, and data modules in addition to the associated source code. Thus, a whole application can be stored in the repository. For example, if you are developing a large client-server application in which all the GUI forms should inherit from a common custom-built form, the common custom-built form should be developed first, including any implementation of the event handlers. Once this form is saved to the object repository, it is available through the ‘New Items’ dialog while creating new projects. New applications can be inherited from the items saved in the repository. This will be clear if you navigate through the different pages within the ‘New Items’ dialog. There are two dialogs used to save new modules into the repository and reorganize them into pages. The first dialog is invoked by placing the cursor on the form (or a data module), clicking the right mouse button, and then selecting the ‘Add to Repository …’ option in the popup menu. This dialog looks similar to Figure 6.17. The entry fields in this dialog are self-explanatory. The page in which the new module should be stored is selected from the drop-down list of pages. New pages can be created using the Object Repository dialog, which is invoked by selecting the Tools ® Object Repository option menu. Figure 6.18 displays a screenshot of this dialog. This dialog is used typically to add new pages, move items across pages, or delete existing pages. The pages created using this dialog will appear in the ‘New Items’ dialog, which is used to add new items to a project or create new projects.