Projekte erstellen und verwalten ist die Hauptaufgabe von Kylix. Mit den Hilfsmitteln der Entwicklungsumgebung behalten Sie den Überblick über ihre Programme, an denen Sie arbeiten.

Nachdem wir im ersten Teil des Workshops zu Linux-Programmierung mit Kylix eine kurze Einführung sowie Kurzübersicht zu Kylix und die Voraussetzungen, Bezugsmöglichkeiten sowie Installation besprochen haben, kümmern wir uns in dem zweiten Teil intensiver um die Oberfläche von Kylix. Das umfasst im Schwerpunkt den Objektinspektor, den Editor, die Komponentenpalette sowie den Formulardesigner.

Ebenso sprechen wir die Arbeit mit Projekten, die verschiedenen Arten der Kylix-Dateien und die Assistenten zur Erstellung von unterschiedlichen Dateitypen an. Das passiert anhand eines praktischen Beispiels auf Basis der Grundkomponenten von Kylix.

Kylix-Projekte

Das Herz von Kylix-Programmierung bilden so genannte Projekte. Bei einer projektorientierten Programmierumgebung fasst man ein die Bestandteile eines Programms zusammen, das nicht nur aus einer oder mehreren Quelltextdateien, sondern beispielsweise auch aus Grafiken bestehen kann. Alle verwendeten Dateien verwaltet Kylix gemeinsam.

Ebenso ist es üblich, das Aussehen eines Formulars in eine eigene Datei abzulegen. Zudem werden eine ganze Reihe von Konfigurationsinformationen der Programmierumgebung zu einem Projekt gezählt und in Begleitdateien gespeichert. Darunter fällt zum Beispiel die Anordnung der IDE-Fenster.

Ein Projekt enthält zahlreiche Dateien, die Sie in der Kylix-IDE nicht unmittelbar sehen und manuell gar nicht berühren müssen. Kylix generiert diese im Hintergrund. Viele Dateien liegen aber in Klartextform vor und können mit jedem beliebigen Editor angesehen und auch geändert werden, obgleich das ziemlich gefährlich sein kann, wenn man sich mit der Syntax nicht auskennt.

Projekte per Mausklick

Grundsätzlich bedeutet das Erstellen eines Linux-Programms mit Kylix also, dass wir erst einmal ein Projekt erstellen. Aus dem Projekt generieren wir das Programm oder eine andere Form von Kylix-Code. Die Kylix-IDE stellt mit der Projektverwaltung im Menü Ansicht eine integrierte Verwaltung für diese Dateien zur Verfügung.

Abbildung 1: Die Projektverwaltung von Kylix

In der Praxis startet Kylix mit einem leeren Projekt für eine Applikation, wenn Sie das Programm starten. Tun wir das. Sie sehen wieder die IDE, wie wir sie schon im ersten Teil von dem Workshop verwendet haben.

Alternativ können Sie über das Menü Datei und dort mit dem Punkt Neu… oder den darunter befindlichen Assistenten im Rahmen der so genannten Objektgalerie eine Vorlage auswählen, über die Sie eine spezielle Form an Kylix-Code generieren.

Das kann eine Applikation, ein Formular, ein Datenmodul, eine Projektschablone oder ein spezieller Experte sein, den Sie als Ausgangspunkt für Ihre Anwendung verwenden wollen. Was alles möglich ist, hängt von der Kylix-Version ab.

Abbildung 2: Kylix stellt zahlreiche Assistenten zum Erstellen verschiedener Arten an Code zur Verfügung – hier die Enterprise-Version

Wir wollen als Erstes das noch nicht von uns erweiterte – also von Kylix beim Start automatisch generierte – Projekt speichern. Gehen Sie in das Datei-Menü und wählen Sie dort den Befehl Projekt speichern unter ….

In den folgenden Dialogen vergeben Sie für die in dem Projekt vorhandenen Dateien Namen und Speicherungsorte. Bei dem Default-Projekt von Kylix sind das die Dateien Unit1.pas und Project1.dpr. Diese Namen sind voreingestellt. Sie können die Namen natürlich ändern.

Die Grundstruktur

Die Grundstruktur eines Kylix-Projektes basiert im Kern auf Strukturen, die bereits in Delphi und davor schon in reinem Pascal vorhanden waren. Das ist einmal die modulare Struktur, die in Pascal verwendet wird: Ein Programm besteht dort – bereits ab einer halbwegs aufwendigen Größe – aus einem Hauptprogramm und einzelnen Modulen, die Units genannt werden. So wird eine logische Aufteilungen von Programmcode vorgenommen.

Jede Unit wird sowohl in Pascal als auch Kylix als einzelne Datei geführt. Die eben gespeicherte Datei Unit1.pas ist – wie der Default-Name ja deutlich macht – so eine Unit mit Pascal-Quelltext.

Aber auch die Datei Project1.dpr ist im Grunde eine Pascal-Unit. Die Dateierweiterung macht jedoch schon deutlich, dass es sich um eine besondere Art von Unit handelt. Diese verwendet man in Kylix und Delphi, nicht aber in klassischen Pascal-Varianten. Dort speichert man die eigentliche Programmquelltextdatei mit der Erweiterung pas.

Die Dateierweiterung dpr kennzeichnet diese Datei als die zentrale Quelltextdatei für das Kylix-Programm und aus deren Namensstamm ergibt sich defaultmäßig der Programmname nach der Erstellung. Im Grunde gibt es aber keinen qualitativen Unterschied zu einer Pas-Datei.

Falls der Formulardesigner sichtbar ist, schalten Sie mit [F12] um. Wenn Sie in der IDE von Kylix den Quelltexteditor sehen, sollte dort folgender Quelltext sichtbar sein:

unit Unit1;
interface
uses
  SysUtils, Types, Classes, Variants, QGraphics, QControls, QForms, QDialogs;
type
  TForm1 = class(TForm)
  private
    { Private-Deklarationen }
  public
    { Public-Deklarationen }
  end;
var
  Form1: TForm1;
implementation
{$R @L: *.xfm}
end.

Das ist die in Kylix verwendete Grundstruktur einer Unit, deren Details wir uns in einem späteren Teil des Workshops annehmen. Wenden wir uns noch dem Inhalt der Datei Project1.dpr zu. Ihn können Sie in jedem normalen Editor oder über die Kylix-IDE ansehen. Sie wählen einfach Projekt und dann Quelltext anzeigen.

Der Inhalt sollte aus aussehen, wie in Listing 2.

program Project1;
uses
  QForms,
  Unit1 in 'Unit1.pas' {Form1};
{$R @L: *.res}
begin
  Application.Initialize;
  Application.CreateForm(TForm1, Form1);
  Application.Run;
end.

Auch wenn Sie Pascal nicht beherrschen, erkennen Sie sicher die Ähnlichkeiten zu dem Quelltext der normalen Unit. Das Dpr-Modul dient im Wesentlichen zum Initialisieren, Verwalten und Starten des Programms. Viel mehr werden Sie in der Datei nicht finden, wenn Sie sie über den normalen Weg der Kylix-IDE erstellen.

Normalerweise müssen Sie diese Datei kaum von Hand anfassen. Nur wenn Sie genau wissen, was Sie tun, sollten Sie hier Änderungen vornehmen. Andernfalls kann der Programmablauf gestört werden und das Programm lässt sich nicht ausführen.

Obwohl diese beiden Dateien die einzigen sind, die Sie beim Speichern explizit benannt haben, generiert Kylix weitere Dateien und Strukturen automatisch, wenn Sie ein Projekt erzeugen. Sie werden diese in der Regel nicht explizit sehen und auch nicht von Hand manipulieren müssen, aber die Projektverwaltung umfasst natürlich auch diese Dateien.

Die Namen der Dateien ergeben sich aus den beiden gespeicherten Dateien. Was die einzelnen Dateiendungen bedeuten, finden Sie in dem Kasten “Kylix-Dateitypen” erklärt.

object Form1: TForm1
  Left = 196
  Top = 137
  Width = 870
  Height = 640
  HorzScrollBar.Range = 379
  VertScrollBar.Range = 169
  Caption = 'Form1'
  Color = clBackground
  PixelsPerInch = 96
  TextHeight = 15
  TextWidth = 6
  object Button1: TButton
    Left = 304
    Top = 144
    Width = 75
    Height = 25
    Caption = 'Button1'
    TabOrder = 0
  end
end

Wir setzen einen drauf und kompilieren das Programm. Das passiert einmal automatisch im Hintergrund, wenn Sie das Programm in der Kylix-IDE einfach mit [F9] oder dem entsprechenden Befehl im Menü Start starten. Sie können die Übersetzung des Quelltextes aber auch mit [Strg+F9] anschieben.

Wenn Sie also das Projekt übersetzen, passiert vereinfacht Folgendes: Der meiste Quelltext wird in Kylix in einer Datei mit der Erweiterung pas abgelegt. Das haben wir schon gesehen.

Daraus und aus ergänzenden Ressourcen wird eine kompilierte Datei mit lauffähigem Binär-Code erzeugt, die den gleichem Namensstamm wie die Quelltextdatei und die Erweiterung dcu bekommt. Aus der Dpr-Datei und den Dcu-Dateien wird ein Programm erzeugt, dass den gleichen Namensstamm wie die Dpr-Datei, aber keine Dateierweiterung bekommt.

Kylix setzt die Attribute dieser Datei dabei auf “Ausführbar”. Wenn Sie im Dateimanager das Arbeitsverzeichnis des Projektes betrachten, werden Sie jetzt dort genau diese zwei zusätzlichen Dateien entdecken.

Mehr zur IDE

Wenden wir uns jetzt der IDE genauer zu – insbesondere dem Objektinspektor. Das Tool ist eine geniale Hilfe beim Festlegen von Eigenschaften und Verhaltensweise von Programmbestandteilen zur Designzeit. Die Programmbestandteile sind im Wesentlichen, aber nicht ausschließlich, Komponenten, die aus der Komponentenpalette per Maus in ein Formular gezogen werden.

Jede Komponente besitzt eine Reihe von spezifischen Eigenschaften (Größe, Farbe, …) und zugeordneten Ereignissen (Klick, Doppelklick, …), auf die das Programm reagieren kann. Wenn Sie eine Komponente über die Komponentenpalette erzeugen, sind deren Komponentenattribute mit Default-Einstellungen vorbelegt, die während der Arbeit an dem Projekt bereitstehen. Daher werden sie im Objektinspektor angezeigt und gelten auch zur Laufzeit des Programms, sofern Sie diese nicht verändern.

Diese Default-Werte können selbstverständlich geändert werden. In einigen wenigen Ausnahmen können Sie allerdings nur gelesen werden. Die Änderungen führen Sie beispielsweise mit einem Editor im Quellcode durch. Das wirkt sich zur Laufzeit aus. Dazu geben Sie im Quelltexteditor den Namen der Komponente ein (zum Beispiel Form1) und weisen der gewünschten Eigenschaft (beispielsweise Caption) den neuen Wert zu. Etwa so:

Form1.Caption := 'Das tolle Programm';

Mit Hilfe der Maus lassen sich im Formular-Designer die Position und die Größe von Komponenten ändern. Das haben wir im ersten Teil des Workshops schon gemacht. Aus diese Weise können aber nicht alle Attribute verändert werden. Etwa hat man so keinen Zugang zur Farbe oder Beschriftung eines Elements.

Ein Kernelement der visuellen Arbeit mit der Kylix-IDE ist der Objektinspektor oder kurz Inspektor und darüber kommen Sie an alle zugänglichen Attribute einer selektierten Komponente. Wenn mehrere Komponenten selektiert werden, etwa, indem Sie diese mit gedrückter [Shift]-Taste nacheinander anklicken, stellt der Objektinspektor die gemeinsamen Eigenschaften dar und diesen können in einem Schritt neue Werte zugewiesen werden.

Sollte der Objektinspektor nicht sichtbar sein, kann er mit der Taste [F11] oder über Ansicht-Menü angezeigt werden. Der Inspektor kann beliebig auf dem Bildschirm angeordnet und vielfältig angepasst werden (Größe, Sortierung, Aufteilung etc).

Am leichtesten kommen Sie an diese Konfigurationsmöglichkeiten über das Kontextmenü im Objektinspektor, worüber Sie auch noch diverse weitere Verhaltensweisen des Inspektors einstellen können. Im Inspektor werden sämtliche Attribute der gerade selektierten Komponente angezeigt.

Der Inspektor fungiert als Bindeglied zwischen dem äußeren Erscheinungsbild der Anwendung mit allen relevanten Fakten und dem Quelltext. Dabei unterscheidet man die Behandlung der Eigenschaften, die in dem linken Registerblatt zu finden sind, und die Erstellung und Behandlung von Ereignisbehandlungsroutinen, deren Zugriff im rechten Registerblatt geregelt ist. Zwischen den Registerblättern wechseln Sie am leichtesten, indem Sie einfach mit der Maus auf das entsprechende Registerblatt klicken.

Abbildung 3: Zugang zu den Eigenschaften einer Komponente über den Inspektor

Abbildung 4: Zugang zu den Reaktionsmöglichkeiten einer Komponente über den Inspektor

Links in jedem Registerblatt finden den Namen des Attributs beziehungsweise des Ereignisses und rechts den gerade aktuellen Wert oder die auszuführende Reaktion. Wird vor einem Eigenschaftsnamen ein Pluszeichen angezeigt, können Sie durch Klicken auf dieses Symbol Untereigenschaften anzeigen lassen.

Wertewandel per Mausklick

Das Symbol verändert sich zu einem Minuszeichen, über das das aufgeklappte Untermenü geschlossen werden kann. Wenn Sie eine Eigenschaft auswählen, ist der Wert rechts markiert und Sie können den Wert in einem Eingabefeld bearbeiten, sofern er nicht nur zu lesen ist.

Dabei muss man unterscheiden, um welchen Typus von Eigenschaft es sich handelt. Kylix stellt über den Objektinspektor diese unterschiedlichen Typen durch geeignete Anzeigemodi verschiedenartig dar bzw. stellt unterschiedliche Zugriffsmöglichkeiten über so genannte Eigenschafts-Editoren zur Manipulation der Werte zur Verfügung.

Hier ist ein kleine Auswahl der wichtigsten Eingabemöglichkeiten. Die einfachste Eingabe erfolgt über ein einzeiliges Eingabefeld über die Tastatur. Eigenschaften, die auf diese Weise manipuliert werden, entsprechen im Allgemeinen Zahlen oder Texten, wobei bestimmte Rahmenbedingung wie Text oder Zahl geprüft werden können.

Weiter finden Sie im Objektinspektor Eigenschaftswerte, die über ein Dialogfeld festgelegt werden können. Meist handelt es sich um komplexere, aber dennoch in einem gewissen Bereich begrenzte Angaben. Etwa Schrifttypen samt Formatierung. Bei diesen Eigenschaften wird – sobald sie im Objektinspektor selektiert sind – eine Schaltfläche mit drei Punkten (…) angezeigt.

Bei Eigenschaften mit einer begrenzten Anzahl an vorgegebenen Werten wird bei einer Selektion in der Wertespalte eine Dropdown-Schaltfläche angezeigt. Es handelt sich hier um einen Editor mit aufklappbarer Liste.

Über das Auswahlfeld am oberen Rand des Objektinspektors gelangen Sie an eine Dropdown-Liste, in der alle Komponenten des aktiven Formulars angezeigt werden. Mit einem Klick auf einen Eintrag können Sie zwischen den einzelnen Komponenten des aktuellen Formulars wechseln.

Ereignisse und der Objektinspektor

Damit ein Programm zur Laufzeit auf bestimmte Situationen reagieren kann, unterstützen fast alle Komponenten bestimmte Ereignisse, bei deren Auftreten eine bestimmte Funktionalität aufgerufen werden kann.

Etwa einen Mausklick durch den Anwender oder das Überstreichen eines Komponentenbereichs mit dem Mauszeiger. Mit Hilfe des rechten Registerblatts im Objektinspektor können Sie Komponenten mit Programmereignissen verknüpfen. Bei jeder Komponente finden Sie eine Liste mit allen davon unterstützten Ereignissen.

Welche Ereignisse bei einer Komponente Sinn ergeben, hängt vom Typ ab. Ein Button wird andere Ereignisse unterstützen als zum Beispiel ein Label. Grundsätzlich besitzt jede Komponente ein Standardereignis. Das ist ein Ereignis, das per Default ausgelöst wird.

Bei vielen Komponenten ist das der Klick. Diesem Standardereignis ist eine Behandlungsroutine zugeordnet, deren Grundschablone, eine leere Routine, Sie in Kylix einfach mit einem Doppelklick auf die Komponente im Formulardesigner erzeugen können.

Dabei wechselt die Kylix-IDE automatisch in den Quelltexteditor und springt zu der Stelle, wo Sie hineinschreiben können, was beim Auftreten dieses Ereignisses passieren soll. Der Name der Routine zur Reaktion auf Ereignisse wird bei der Generierung der Codeschablone automatisch generiert. Er ergibt sich nach festen Kriterien.

Vor dem Punkt finden Sie den Namen des Objekts, auf dem sich das Ereignis abspielt, zum Beispiel der Name des Buttons. Hinter dem Punkt kommt der eigentliche Name der Routine. Dieser setzt sich aus dem Namen der Komponente und dem spezifizierten Ereignis zusammen.

Wenn Sie also auf einer Form mit dem Namen TForm1 einen Button einfügen, erhält dieser als Standard den Namen Button1. Soll das Ereignis Click unterstützt werden, ergibt sich automatisch der Name TForm1.Button1Click.

Verändern Sie später den Namen einer Komponente zum Beispiel im Objektinspektor, passt die Software die Namen der zugeordneten Ereignismethoden automatisch an. Spezifizieren Sie bei einer Komponente statt dem Standardereignis ein anderes Ereignis, können Sie einfach im Inspektor in der entsprechenden Zeile im rechten Registerblatt mit den Events einen Doppelklick ausführen und eine passende Schablone wird generiert. Der Name der generierten Schablone setzt sich wie beim Standardereignis aus dem Namen der Komponente und der Art des Ereignisses zusammen. Alle Ereignisse, die eine Komponente unterstützt, werden namentlich im Objektinspektor angezeigt.