AMIGA-Magazin · Ausgabe 4/06 · AmigaOS 4: Programmierkurs Teil 1

Aktuelles Heft 4/06

Startpunkt

Unser neuer Programmierkurs soll als Einstiegshilfe für die Entwicklung von "AmigaOS 4"-Applikationen dienen. Als Startschuss stricken wir uns ein Grundgerüst.

von Michael Christoph

Dieser Kurs baut auf den Grundlagenartikeln zur Programmierung unter "AmigaOS 4" aus dem Amiga Magazin ab Ausgabe 7/2004 auf. Er soll anhand des konkreten Projekts das Zusammenspiel einzelner Systemfunktionen genauer erläutern. Außerdem soll die Artikelreihe grundlegende Punkte zum Design und Aufbau eines Programms vorstellen. Darum wird nicht mehr im Einzelnen auf alle Funktionen eingegangen, sondern auf die bisherigen Teile verwiesen. Es wird also mehr Beschreibungen zum Sourcecode geben und weniger Aufzählungen der Betriebssystemfunktionen.

Dieser Kurs richtet sich an Personen, die bereits Erfahrungen mit der Programmierung haben. Er stellt speziell die Benutzung der neuen "AmigaOS 4"-Funktionen in den Vordergrund. Als Beispiel soll ein Haushaltsbuch dienen. Dabei werden Benutzeroberflächen (per Reaction) erstellt und Listen zur Verwaltung von Einträgen erzeugt. Zusätzlich speichert das Beispiel die Programmeinstellungen über Prefs-Objekts und die Einbindung in die AmiDock-Leiste soll eine Rolle spielen. Für die Unterstützung des Beispiels benötigen Sie den SDK für "AmigaOS 4". Die Quelltexte zu den Artikeln finden Sie auf der CD zum Heft.

In diesem Kurs stehen vor allem die neuen Möglichkeiten von "AmigaOS 4" im Vordergrund. Deshalb wird auf die Kompatibilität zu älteren Betriebssystemversionen verzichtet. Entweder müssten Sie dann auf alle neuen Funktionen verzichten oder diese aufwändig nachprogrammieren.

Start mit main
Das Programm bekommt gleich die erste Funktion, die main heißt (siehe Listing 1). Diese muss bei jedem Programm vorhanden sein und wird als erstes ausgeführt. Zur Unterscheidung, ob das Programm von der Shell oder der Workbench gestartet wurde, wird das Übergabeargument argc abgefragt. Das ist schon vom SAS-Compiler aus alten Amiga-Tagen bekannt. Ist der Übergabewert gleich 0, dann ist argv ein Zeiger auf die WBStartup-Message der Workbench. Ansonsten existiert ein Array mit Übergabewerten. Shell-Parameter sollten aber über die Anweisung IDOS->ReadArgs() ausgewertet werden, um dem Anwender eine einheitliche Bedienung zu ermöglichen. Falls sich ein Programm in der AmiDock-Leiste anmelden möchte, geht das nur, wenn es von der Workbench in "AmigaOS 4" gestartet wurde.

Das Öffnen und Schließen der Libraries und OS4-Interfaces wollen wir uns an dieser Stelle sparen. Stattdessen kommt der AutoInit-Code zum Einsatz. Linken Sie mit der Option lauto. Auch die später noch benötigten Klassen für Reactionen lassen sich automatisch öffnen und schließen. Hier heißt die Linkoption -lraauto. Da das Programm in späteren Versionen auch mit Fließkommazahlen für Geldbeträge umgehen muss, wird noch die Mathematik-Bibliothek benötigt. Diese lässt sich mit dem Parameter -lm hinzulinken.

Makefiles machen das Leben leichter
In den folgenden Teilen dieses Kurses werden immer mehr Sourcecode-Dateien erstellt, übersetzt und gelinkt, um das fertige Programm zu erzeugen. Um nun nicht jedesmal mühsam von Hand die Übersetzungsanweisungen einzutippen, empfielt sich die Verwendung eines Makefiles. Darin enthalten sind Regeln, wie das Programm zu erstellen ist (z.B. Compilierungs-Optionen) und auch welche Dateien zum Programm gehören. Dann reicht die Eingabe des Befehls make aus, um alles zusammenzustellen. Für das Beispielprojekt sind nur wenige Zeilen wirklich wichtig und müssen angepasst werden. Der Rest kann als funktionsfähig vorausgesetzt werden. Weitere Informationen zu "Make" findet man in der Dokumentation.

In Listing 2 finden Sie ein Beispiel für ein Makefile. Sie müssen es bei Bedarf anpassen. Beachten Sie: Das Makefile sollte mit einem Editor bearbeitet werden, der Tabulatoren speichern kann und diese nicht in Leerzeichen umwandelt.

Besondere Bedeutung hat die Option -Wall. Damit werden alle Warnungen beim gcc aktiviert, sodass auch kleine Grenzüberschreitungen vom gcc angemahnt werden. Damit beugt man Fehlern im Programm vor - Beispiel: Mehrere Funktionen mit demselben Namen oder auch gleichlautende Variablen in unterschiedlichen Quellcode-Dateien. Man sollte also immer darum bemüht sein, dass vom Compiler keine Warnungen ausgegeben werden. Ganz Hartgesottene können auch -Werror benutzen. Dies bewirkt, dass Warnungen als Fehler bewertet werden und zum Abbruch des Compilierungsvorgangs führen. Eine vollständige Liste der Optionen ist in der gcc-Dokumentation im SDK zu finden.

Benutzerrückmeldungen
Man kann es gar nicht oft genug wiederholen, wie wichtig Benutzerrückmeldungen speziell auch bei Fehlern im Programm sind. Es gibt zwei Arten von Rückmeldungen. Einmal eine Mitteilung an den Benutzer, wenn z.B. der Speicher nicht ausreicht, eine Eingabe fehlt oder wenn eine Datei nicht geöffnet werden kann. Auf der anderen Seite die Auswahlmöglichkeiten, bei denen der Nutzer wählen kann. Beispiel hierfür: geänderte Daten speichern oder Prüfung ob Einträge wirklich gelöscht werden sollen.

Intern ist allerdings keine Unterscheidung notwendig, da AmigaOS die Anzahl der Schalter dynamisch erweitern kann. Bisher wurden für derartige Fenster auf die Easy-Requester zurückgegriffen, da diese mit wenigen Zeilen Code zu erstellen waren. Ein Schattendasein führte daher bisher die requester.class, welche seit "AmigaOS 2.x" theoretisch verfügbar ist. Mit "AmigaOS 4" wurde sie aber nochmals aufgewertet und kann jetzt auch ein Symbol im Fenster mit anzeigen.

Dazu stehen entweder die sechs internen Symbole zur Verfügung: REQIMAGE_xxx ist in classes/requester.h zu finden. Alternativ erstellen Sie selber ein Image über eine Bitmap-Klasse. Das hat auch den Vorteil, dass die Bilddaten extern auf der Platte vorliegen können und so einfach durch andere ersetzt werden können. Für eigene Bilder können alle Grafikformate zum Einsatz kommen, die durch Datatypes unterstützt werden.

Kann das externe Image nicht gefunden werden, ist der entsprechende Zeiger Null. Das interpretiert die Requester-Klasse als "anzeigen des Default-Symbols". Das fertige Codegerüst ist als wiederverwendbare Funktion DisplayRequester() in der Datei myKassenbuchDocky.c zu finden. Hinweis: Die Requester-Funktion kann eine beliebige Anzahl an Argumenten verarbeiten. Das wird als Elipsen-Argument ausgedrückt.

Benötigte Komponenten
Alle angesprochenen Quellcodes sind in der jeweiligen Ausbaustufe auf der Heft-CD des Amiga Magazin zu finden. Benötigt wird neben "AmigaOS 4" auch das SDK mit den Include-Dateien. Empfehlenswert ist, die letzte Version V51.15 zu verwenden. Mit dem nächsten Teil ist es Pflicht, da erst in diesem SDK die Includes zur application.library enthalten sind. Im SDK finden Sie neben dem "gcc" den "g++"-Compiler und andere Tools (make, idltool, strip). Als Ergänzung können Sie noch einen alternativen Editor oder eine grafische Entwicklungsumgebung nutzen.

Einen Timer nutzen?Eigentlich braucht ein Kassenbuch keine zeitgesteuerten Funktionen. Und sogar die Uhranzeige in der Dockleiste lässt sich vollständig ohne timer.device realisieren, wie der nächste Kursteil zeigen wird. Trotzdem wird oftmals ein Timer benötigt und so lässt sich dieses Grundgerüst auch für andere Projekte verwenden.

Im Prinzip ist die Anwendung nicht sehr kompliziert. Es ist ein Nachrichtenport mit IExec->CreatePort zu erstellen. Die Verwaltungs-(Nachrichten)-Struktur legt man mit IExec->CreateIORequest an, um damit das timer.device zu öffnen. Unter "AmigaOS 4" muss zusätzlich noch das Interface geöffnet werden, falls die Library-Funktionen wie ITimer->GetSysTime benutzt werden sollen. Über den Aufruf IExec->SendIO() wird der Timer gestartet und kehrt nach Ablauf als Nachricht ins Programm zurück.

Wirklich kompliziert wird es nur beim Schließen. Falls der Timer noch nicht abgelaufen ist, das Programm aber trotzdem beendet werden soll (oder auch einfach nur eine Warteaktion abgebrochen werden soll) muss zuerst der ausstehende Timer abgebrochen werden. Dazu nutzt man IExec->AbortIO und auf das Ende der Abbruchaktion wartet IExec->WaitIO. Die Funktionen an sich sind sicher, sodass auch bereits abgelaufene Timer abgebrochen werden können, was natürlich ohne weitere Aktion bleibt.

Die vollständige Anwendung ist im dokumentierten Sourcecode auf der Heft-CD zu dieser Ausgabe zu finden. Er gibt Fehlermeldungen aus, wenn der Timer nicht erstellt werden kann.

Damit ist der erste Teil auch schon abgeschlossen. In der nächsten Ausgabe wird dann endlich auch etwas zu sehen sein, da sich unser Programm in die AmiDock-Leiste einfügen wird. Zuständig dafür ist die neue application.library.

lb


Projektvorschau:
So soll das komplette Kassenbuch zu diesem Kurs einmal aussehen.

 

Abfragebeispiel:
Ein Requester mit Image in einer Anwendung unter "AmigaOS 4".

 

Kursübersicht
Teil 1:Ein Grundgerüst mit Makefile
Teil 2: Eindocken ist angesagt
Teil 3: Bedienbar wird es mit Reaction
Teil 4: Man erinnert sich mit XML
Teil 5: Eine Artikeldatenbank finden

 


Hauptseite © 2006 All Rights Reserved. Alle Rechte vorbehalten Franzis' Verlag GmbH
Veröffentlichung und Vervielfältigung nur mit schriftlicher Genehmigung des Verlags

Kommentare, Fragen, Korrekturen und Kritik bitte an Webmaster AMIGA schicken.
Zuletzt aktualisiert am 26.3. 2006.