ATOS-Magazin Juni/Juli 1997 |  | # Phoenix 5.0 Von Martin Miethke Das Datenbank-Programm Phoenix hat seit vielen Jahren einen festen Platz in der TOS-Welt. Seine Stärke liegt vor allem in der Möglichkeit, sehr umfangreiche und komplexe Anwendungen mit komfortabler Oberfläche erstellen zu können. Für die Ausgabe auf den Drucker oder in eine Datei steht die "Report"-Funktion zur Verfügung, die zwar sehr viele Möglichkeiten bietet, aber auch einige schwerwiegende Nachteile hat. Dazu gehört vor allem die umständliche Handhabung des textorientierten Report-Generators mit Platzhaltern und Schlüsselwörtern; das Ergebnis kann nur mit sehr viel Erfahrung einigermaßen abgeschätzt werden. Auch daß aus einem Report nicht auf die mächtigen Rechenfunktionen von Phoenix zugegriffen werden kann und auch die Ausgabe rein textorientiert erfolgt, also nur druckerinterne Schriften genutzt werden können, läßt manchmal mehr Frust als Freude aufkommen. Ein lange gehegter Wunsch vieler Anwender betraf demnach einen einfacher zu handhabenden Reportgenerators sowie den Ausdruck über GDOS. Und genau dieser Wunsch wurde nun in der Version 5 von Phoenix Wirklichkeit. Inwieweit die Umsetzung geglückt ist, erfahren Sie in diesem Testbericht. Eine weitere Neuerung betrifft die Umstellung der Online-Hilfe auf den ST-Guide, die Unterstützung des OLGA-Protokolls und den Desktop; auch darauf werde ich kurz eingehen. Inhalt:
| Installation und erster Eindruck
| Der grafische Bericht
| Verschiedenste Einstellungen
| Rechnen im Bericht
| Mehrzeilige Textfelder
| Phoenix und OLGA
| Fazit
Bezugsquelle:
Adresse: | Application Systems Heidelberg GmbH Postfach 102 646 D-69016 Heidelberg
Telefon: | 06221/300002
Telefax: | 06221/300389
Modem: | 06221/303671
eMail: | Volker Ritzhaupt @ KA2 Oliver Buchmann @ KA2 100067,3712 (Compuserve-ID) 100067.3712@compuserve.com
### Phoenix-Installation Das Update besteht aus einer HD-Diskette (auf Wunsch werden auch zwei DD-Disketten geliefert) und einem ungewohnt dicken Hand"heft". Nach Durchsicht dieses Heftes wird jedoch klar, daß es sich hier nicht um ein Ergänzungshandbuch zur neuen Version handelt (nicht einmal die Änderungen zur Vorversion sind dokumentiert), sondern um das Handbuch. Dicke, ausführliche Programm-Dokumentationen sind im heutigen TOS-Markt leider völlig unrentabel geworden; wohl denen, die noch ein "richtiges" Handbuch aus früheren Zeiten besitzen. Die Installation gestaltet sich durch das bekannte Installationsprogramm gewohnt einfach und komfortabel. Dabei fällt auf, daß die Einträge "Manager Hilfe" bzw. "Designer Hilfe" fehlen; dafür steht da nun "ST-Guide und Online-Hilfe", was schon auf eine der Änderungen in Phoenix 5.0 hinweist. Nach erfolgreich abgeschlossener Installation (siehe dazu auch den Tip im Kasten) ist der neue Phoenix dann startklar. Spezial-Tip Phoenix: Installation Sollten Sie sich wundern, daß sich das ST-Guide-Hilfesystem nur zusammen mit den Demo-Datenbanken installieren läßt - das liegt an einem Fehler in der SETUP.INF, den Sie ganz leicht selbst beheben können: Die Zeilen 143 bis 149 beginnen mit "$06"; hier brauchen Sie nur aus der 6 eine 2 zu machen, so daß die Zeilen nun mit "$02" anfangen. Beim ersten Start kommt dann erst einmal Verwunderung auf: trotz der laut Ankündigung jetzt vorhandenen Unterstützung von GDOS (genauer: NVDI) werden immer noch die Vektorfonts eingelesen, was bei einer größeren Anzahl derselben also weiterhin zu einer lästigen Wartezeit führt. Ist das Programm dann geladen, erscheint der altgewohnte Desktop, was die Frage aufwirft, ob der denn unter Multitasking-Systemen immer noch nicht abschaltbar ist. Der Readme-Text klärt jedoch darüber auf, daß sich der Desktop nun in ein Fenster legen läßt, was dann auch problemlos klappt. Diese Lösung ist natürlich noch besser; Phoenix ganz ohne Desktop wäre denn doch schlecht vorstellbar. Etwas verwirrend ist hier nur, daß beim Verschieben eines Icons (z.B. auf ein Reportfenster) der "Verschiebe-Rahmen" am Rand des Desktop-Fensters "hängenbleibt". Dies erweckt fälschlicherweise den Eindruck, daß Drag & Drop mit den Tabellen- oder Klemmbrett-Icons gar nicht funktioniert, obwohl dies natürlich weiterhin möglich ist. Hilfe! Die Online-Hilfe wurde auf den inzwischen weit verbreiteten Hypertext-Browser ST-Guide von Holger Weets umgestellt. An sich ja eine positive Veränderung, die sicher die meisten begrüßen werden; allerdings wurde sie doch recht halbherzig (oder unter Zeitdruck?) durchgeführt. Die Hypertexte sind noch sehr überarbeitungsbedürftig und enthalten etliche Fehler; so funktionieren z.B. einige Verweise nicht, es fehlt das eine oder andere (z.B. manche Rechenfunktionen), und die Erklärung der Icons des Bericht-Fensters macht ohne die Abbildung dieser Icons wenig Sinn. Witzig ist auch, wenn in der Online-Hilfe auf "ausführliche Informationen in der Online-Hilfe" hingewiesen wird - es ist ganz offensichtlich, daß es sich bei großen Teilen der Hypertexte um 1:1-Kopien des Handbuchs handelt. Nicht zu Ende gedacht wurde diese Umstellung auch bei der benutzerdefinierten Hilfe. Das Verhalten von Hilfe-Buttons ist nun inkonsistent: Mit einem entsprechenden "Aktionsknopf" in einer Maske ist es weiterhin möglich, den zugehörigen Datensatz einer selbstgebastelten Hilfe-Datenbank aufzurufen (diese muß nun allerdings "MANAGER" statt "MANHELP" heißen). Dagegen führt das Betätigen eines Hilfe-Knopfes in einem per Rechenprozeß erzeugten Alert dazu, daß Phoenix im MANAGER.HYP nach einer Seite mit entsprechendem Namen sucht und, wenn diese nicht vorhanden ist, die Index-Seite dieses Hypertextes auf den Bildschirm bringt. Hier sollten sich die Programmautoren noch entscheiden: User-Hilfe entweder mit Phoenix-Datenbank oder ST-Guide-Hypertext. Noch besser wäre es natürlich, wenn sich die Anwender für eine der beiden Möglichkeiten entscheiden könnten - schließlich ist auch das Erstellen eines eigenen Hypertextes keine große Schwierigkeit. ### Grafischer Bericht Phoenix als Layout-Programm Wie bereits in der Einleitung erwähnt, wurde in Phoenix 5.0 die Ausgabe-Funktion gründlich überarbeitet. Es handelt sich hier aber nicht um eine Erweiterung des alten Reports, sondern um einen völlig neuen Programmteil mit ganz anderem Konzept; das Ganze nennt sich "grafischer Bericht". Im Gegensatz zum Report ist dieser "Bericht" voll objektorientiert. Die Positionen der einzelnen Elemente werden hier nicht mehr über kryptische Befehlsfolgen, sondern sehr bequem mit der Maus bestimmt; die Handhabung erinnert stark an ein Vektorgrafik-Programm. Alle verfügbaren Elemente werden als Rahmenobjekte mit "Anfassern" dargestellt, die sich beliebig verschieben und in der Größe verändern lassen. Der Umgang mit solchen Rahmen dürfte den meisten von Ihnen aus DTP-Programmen (wie Calamus) oder Vektorgrafik-Programmen bekannt sein und ist sehr einfach und intuitiv begreifbar. Nur die Tatsache, daß selbst Linien (die hier leider nur waagerecht oder senkrecht verlaufen können) auf diese Weise dargestellt werden, ist zumindest gewöhnungsbedürftig. Auch die Aufteilung der Seite, besonders die bisher so umständliche und schwer zu durchblickende Handhabung von Kopf- und Fußzeilen, ist jetzt ein Kinderspiel; die entsprechenden Bereiche werden im "Quasi-WYSISYG-Verfahren" dargestellt, und ihre Größe kann ganz einfach mit der Maus verändert werden. Zusätzlich zu den Kopf- und Fußzeilen für jede Seite können Sie jetzt auch einen Bereich festlegen, der nur am Anfang der ersten bzw. am Ende der letzten Seite erscheint. Über entsprechende Menübefehle können diese Bereiche je nach Bedarf ein- und ausgeblendet werden. Daß diese nur auf Kopf und Fuß gemeinsam wirken, ist kein Problem: wollen Sie z.B. nur eine Kopfzeile, brauchen sie den Seitenfuß einfach nur auf die Größe 0 zu reduzieren. In obiger Abbildung sehen Sie auch die "Online-Anzeige" in der Infozeile. Beim ersten Aufziehen eines Rahmens oder bei einer nachträglichen Größenänderung werden hier die zugehörigen Daten (Koordinaten, Abmessungen und sogar - abhängig vom verwendeten Font - die maximal mögliche Zeilenzahl (!)) angezeigt und permanent aktualisiert. Das Gleiche gilt für die Größenänderung eines Seitenbereichs. Leider gibt es jedoch keine Anzeige der Koordinaten beim Verschieben von Objekten. Objekttypen Im grafischen Bericht stehen verschiedene Objekttypen zur Verfügung. Als erstes natürlich die "Platzhalter", die den Inhalt eines Datenbank-Feldes aufnehmen. Ein Textobjekt ist für die Darstellung von Text zuständig, der sich nicht ändern soll; außerdem können können Sie hier auch die Rechenfunktionen der mächtigen Programmiersprache von Phoenix verwenden! Linien- und Rahmen-Objekte sind bereits aus der Masken-Gestaltung des Designers bekannt. Als Besonderheit (deren Sinn mir allerdings noch nicht klar ist) gibt es dann noch die Radioknöpfe, Checkboxen und "Gruppierungsrahmen". Noch nicht implementiert, aber für eine der folgenden Versionen geplant und bereits als (nicht aktivierbares) Icon vorhanden, ist die Einbindung von Grafiken. Unpraktisch ist, daß sich der Objekttyp nachträglich nicht mehr ändern läßt (besonders für die Umwandlung eines Datenfeldobjektes in ein Textobjekt besteht häufig Bedarf); eine große Arbeitserleichterung ist dagegen das einfache Kopieren von Objekten durch Verschieben mit der Maus bei gehaltener Shifttaste. Mit einer speziellen Option (das Icon mit dem Schloß) lassen sich außerdem Objekte vor versehentlichen Änderungen schützen. Verzweigungen ... waren ja bereits in Reports möglich, dort allerdings war die Handhabung ziemlich umständlich und fehlerträchtig. Im Bericht geht es deutlich einfacher: hier funktionieren sie genau nach demselben Schema wie die Untermasken. Sollen z.B. zu einem Index alle Datensätze einer untergeordneten Tabelle aufgelistet werden, legen Sie dafür einen eigenen Bericht an. Kopf- und Fußzeilen ergeben hier natürlich keinen Sinn und werden daher mit den betreffenden Menübefehlen abgeschaltet. Die Höhe des Detailbereichs stellen Sie entsprechend der gewünschten Zeilenhöhe ein. Im "Hauptbericht" wird dann ein spezieller Rahmen für Unterberichte aufgezogen; hier geben Sie u.a. den Namen des Unterberichts ein sowie den Index in Quell- und Zieltabelle, über den verzweigt werden soll. Auch mehrfach geschachtelte Verzweigungen sind (wie im Report) möglich; ein schönes Beispiel dafür zeigt die beiliegende Kunden-Datenbank. ### Einstellungssache Ein Doppelklick auf ein Objekt öffnet ein Eigenschaften-Fenster, in dem sämtliche Parameter bestimmt werden können. Die Vielzahl der Einstellungsmöglichkeiten ist geradezu überwältigend - hier bleiben wirklich kaum Wünsche offen. Größe von Rahmen und Text; Farbe von Linien, Rand, Hintergrund und Text; Dicke und Art von Linien und Umrandung; Formatierung von Text; Schriftfarbe, -größe und -stil und noch sehr viel mehr lassen sich hier festlegen - in dieser Hinsicht ist Phoenix fast schon ein Layout-Programm. Vermißt habe ich allerdings die Möglichkeit, einen Zeilenabstand zu bestimmen. Übrigens können im selben Fenster auch die Parameter für die Seitenbereiche angezeigt und verändert werden; dazu müssen Sie nur einen Doppelklick auf eine freie Stelle des betreffenden Bereichs oder den zugehörigen Titelbalken machen. Die Einstellungen für die Gesamtseite werden durch Doppelklick auf das horizontale Lineal erreicht. Die Bedienung dieses Fensters ist leicht begreifbar, aber teilweise etwas umständlich. Für die Eingabe steht nur ein einzeiliges Editfeld zur Verfügung; sogar der Text eines Textobjektes kann nur hier bearbeitet werden. In diesem Fall wäre es doch wesentlich einfacher und "intuitiver", wenn man den Inhalt von Textobjekten direkt im Rahmen eingeben könnte. Das Eigenschaften-Fenster kann ständig offenbleiben und zeigt immer die Einstellungen des gerade im Berichtfenster selektierten Objekts; dies ist besonders auf großen Bildschirmen sehr praktisch. Um nun nacheinander mehrere Objekte zu ändern, muß aber immer noch zwischen den beiden Fenstern hin- und hergewechselt werden; der Gipfel an Komfort wäre erreicht, wenn das Berichtfenster im Hintergrund bedienbar wäre! Wünschenswert wäre auch noch, daß Größe und Position des Eigenschaften-Fensters in der Konfiguration gesichert werden. Was jetzt schon möglich ist: mehrere Objekte können (bei gehaltener Shift-Taste) selektiert und gemeinsam im Eigenschaften-Fenster verändert werden. Dabei verhalten sich die Parameterfelder wie beispielsweise vom Mac her bekannt: für Parameter, deren Werte sich in den einzelnen Objekten unterscheiden, bleibt die entsprechende Zeile leer. Ist z.B. die Schriftgröße in einem Objekt 8 Punkt, im nächsten 10 und in einem dritten 14 Punkt, wird unter "Schriftgröße" nichts angezeigt. Ändern Sie hier nichts, werden auch die Werte in den Objekten belassen; stellen Sie dagegen etwas ein, bekommen alle Objekte die neue Schriftgröße. Mehrere Spalten Auf eine interessante und oft gewünschte Anwendungsmöglichkeit möchte ich noch kurz eingehen, die sich nun mit dem Bericht realisieren läßt: der mehrspaltige Ausdruck! Die Bedienung ist auch hier wieder ganz einfach: Sie geben im Eigenschaften-Fenster einfach nur die Anzahl der Spalten und deren Abstand untereinander ein, den Rest erledigt Phoenix. In diesem Zusammenhang gibt es aber leider eine Einschränkung: Da sich die Breite von Kopf- und Fußzeilen nicht unabhängig von der Breite des "Detailbereichs" (so wird im Bericht der Hauptteil einer Seite genannt) einstellen läßt, sind bei mehrspaltigem Ausdruck keine spaltenübergreifenden Kopf-/Fußzeilen möglich. Insgesamt ist der grafische Bericht jedoch schon sehr gut gelungen und gäbe einen hervorragenden Serienbrief-Generator ab, wenn - ja, wenn die Anwender nicht zur Texteingabe auf ein einzeiliges Editfeld angewiesen wären. Dies stellt eine erhebliche Einschränkung der Möglichkeiten dieses neuen Phoenix-Features dar. Die Möglichkeit der direkten Texteingabe im Objektrahmen oder die Unterstützung eines Texteditors als OLGA-Server, wie sie ja bereits in Masken-Feldern realisiert ist, sollte hier unbedingt noch eingebaut werden. Der alte "Report" bleibt weiterhin Bestandteil von Phoenix. Zum einen hat das einfach Kompatibilitätsgründe. Phoenix ist nämlich mindestens seit der Version 3.0 sowohl aufwärts- als auch abwärtskompatibel; d.h. Sie können nicht nur eine mit der 3er-Version erstellte Datenbank in Phoenix 5.0 laden, sondern auch umgekehrt. Im zweiten Fall sind halt einige Funktionen nicht verfügbar; z.B. werden Untermasken einfach nicht angezeigt oder ein Multi-Knopf hat keine Wirkung. Es gibt aber einen weiteren, eher noch wichtigeren Grund für die Beibehaltung der Report-Funktion: nur auf diesem Wege ist die Ausgabe in eine Textdatei möglich! Außerdem sind auch hier durch Verwendung von Controlcodes (siehe Tip!) viele Spezialanwendungen realisierbar. Spezial-Tip Phoenix: Control-Codes im Report Und es geht doch - im Report lassen sich Controlcodes auch ohne das umständliche {$ASCII=nnn} einsetzen, sogar in Kopf- und Fußzeilen! Das Zauberwort heißt "Import" - über ^I bzw. "Datei/Importieren" lassen sich beliebige Dateien ins Reportfenster holen, die auch Control-Codes (also Zeichen mit einem ASCII-Code <32) enthalten können. Obwohl eine direkte Eingabe solcher Zeichen nicht möglich ist, werden sie nach dem Importieren ganz normal angezeigt und beim Ausführen des Reports auch richtig ausgegeben. ### Rechnen im Bericht Von einem Bericht aus kann man auch endlich innerhalb der Druckausgabe auf die Programmiersprache (Rechenfunktion) von Phoenix zugreifen. Damit ist es jetzt nicht mehr notwendig, nur für die Ausgabe bestimmter Berechnungen extra Felder oder Tabellen anlegen zu müssen. Auch ist man damit wesentlich flexibler, wenn es darum geht, die Ausgabe eines Feldinhaltes und/oder Textes vom Inhalt bestimmter Datenfelder abhängig zu machen, als mit den entsprechenden Reportfunktionen ({Feldname, "Text"} und {%Feldname}). Meine im Vorabbericht in der letzten ATOS-Ausgabe aufgestellte Behauptung, daß so etwas überhaupt nur in einem Report möglich sei, muß ich also hiermit revidieren. Wie funktioniert das? Zunächst müssen Sie dafür ein Textobjekt anlegen, da in einem Datenfeld-Objekt keine Berechnungen möglich sind (gerade hier macht es sich negativ bemerkbar, daß sich der Objekttyp nachträglich nicht mehr ändern läßt). Diesem Objekt wird nun eine Rechnung zugewiesen, indem Sie mit einem Doppelklick in den Objektrahmen das Eigenschaften-Fenster öffnen und unter "Text" die Rechnung eintragen. "Was?", werden Sie jetzt fragen, "in diesem mickrigen Editfeld soll ich eine ganze Rechnung unterbringen?" Nun, es geht wirklich! Dabei können Sie zwischen zwei verschiedenen Methoden wählen. Erste Möglichkeit: Sie können die Rechnung hier direkt als Text eintragen. Zum Editieren solch einer "internen" Rechnung steht Ihnen jedoch tatsächlich nur dieses Editfeld zur Verfügung - und leider läßt sich der Text weder ins Klemmbrett kopieren noch an einen OLGA-Server übergeben. In der Praxis werden Sie diesen Weg also nur bei sehr einfachen Rechnungen beschreiten. Die zweite, "elegantere" Möglichkeit: Sie schreiben die Rechnung ganz normal wie bisher in einem Rechenfenster (F8) und geben dann im Bericht als Text für das betreffende Objekt einfach nur den Namen dieser Rechnung an. Dabei muß jedoch eine Besonderheit beachtet werden, die ich weiter unten noch näher erläutere. Ganz einfach ... Ich beschreibe einmal das Vorgehen anhand von zwei Beispielen. Eine einfache Anwendung ist das Ausdrucken von Adressen-Etiketten. Da die Position der Objekte im grafischen Bericht prinzipbedingt feststeht, können Sie hier nicht einfach jeweils einen Platzhalter für "Vorname" und "Name" einsetzen - je nach Länge des Vornamens ergäbe das eine unschöne Lücke. Um diese zu vermeiden, fassen Sie mit dem Additions-Operator die beiden Felder (mit dazwischengeschaltetem Leerzeichen) zusammen: Das Gleichheitszeichen am Anfang ist nötig, damit Phoenix erkennt, daß es sich hier um eine Rechnung handelt. Ansonsten gelten die gleichen Regeln wie bisher beim Schreiben einer Rechnung: fester Text wird in doppelte Hochkommas eingefaßt; Feldnamen, Variablen und Zahlen nicht. Dies war ja nun eine sehr einfache Rechnung, die Sie ohne weiteres direkt im Eigenschaften-Fenster eingeben können; sie wird in diesem Fall, wie auch in der Abbildung zu erkennen war, nicht mit einem Semikolon abgeschlossen. Daher hier noch ein zweites Beispiel ... ... und etwas komplizierter Sie möchten eine Liste Ihrer Kakteensammlung ausdrucken. Einige der Kakteen haben zusätzlich einen Varietätsnamen, dieser soll mit vorangestelltem var. hinter dem Artnamen erscheinen: Notocactus crassigibbus Ritt. Notocactus ottonis (Lehm.) Berg. var. vencluianus Schütz Bisher hätten Sie dazu dieses var. überall im Feld "Varietät" mit eingeben müssen, weil es im Report nicht möglich ist, abhängig vom Inhalt eines Feldes einen Text vor dem Feldinhalt auszugeben. Mit Phoenix 5.0 läßt sich das Ganze nun viel eleganter lösen. Sie öffnen ein Rechnungsfenster (F8) und schreiben folgende Rechnung:
        var erg;
        if Varietät<>'' then
            erg=Art+" var. "+Varietät;
        else
            erg=Art;
        end;
        erg=return(erg);
Hier muß ich auf eine wichtige Besonderheit hinweisen: soll ein Rechenprogramm, das mehr als ein Kommando enthält, in einem Bericht verwendet werden, dann müssen Sie am Schluß dieser Rechnung die Funktion return benutzen. Diese hat die Aufgabe, das Rechnungsergebnis an den Bericht zu übergeben (die Wertzuweisung in der return-Funktion muß aus syntaktischen Gründen erfolgen, obwohl sie eigentlich überflüssig ist; hier kann also eine beliebige Variable stehen). Diese Rechnung speichern Sie nun z.B. unter dem Namen "B: Name" ab. Das B: macht sie in der Rechnungsliste auf den ersten Blick als von einem Bericht verwendete Rechnung kenntlich und verbessert so die Übersicht. Im Berichtfenster geben Sie dann für das betreffende Textobjekt nur noch den Rechnungsnamen an: =@B: Name Der Klammeraffe zeigt an, daß danach keine Rechnung folgt, sondern ein Rechnungs-Name; dieser darf nicht in Hochkommata eingeschlossen werden. Auch hier muß zu Beginn das Gleichheitszeichen stehen, sonst druckt Phoenix die Zeile so aus, wie sie da steht. In eine solche Rechnung lassen sich auch die vom Report her bekannten Variablen für Seitenzahlen, Systemdatum etc. verwenden. Da sie weder im Handbuch noch in der Online-Hilfe erwähnt werden, möchte ich sie hier kurz erklären:
{PAGE} | (Seitenzahl)
{COUNT} | (laufende Datensatz-Nummer)
SYSDATE | (Systemdatum)
SYSTIME | (Systemzeit)
SYSTIMESTAMP | (Systemdatum und -zeit)
Um also beispielsweise die Datensatznummer in der Form "Nr. 1" auszugeben, müssen Sie folgendes eingeben: ="Nr. "+{COUNT} ### Mehrzeilige Textfelder Mehrzeilige Textfelder auszudrucken, war mit der bisherigen Reportfunktion oft ein Problem. Entweder wurde einfach alles hintereinandergehängt, oder man mußte die Formatierung aus der Maske übernehmen. Leerzeilen wurden dabei aber immer ignoriert! So war es u.U. gar nicht möglich, das gewünschte Ergebnis zu erzielen. Im grafischen Bericht von Phoenix 5.0 wurde dieses Problem nun optimal gelöst. Das Ergebnis hängt in erster Linie davon ab, ob im jeweiligen Textfeld der automatische Wortumbruch eingeschaltet wurde. Ist das der Fall, behandelt Phoenix diesen Text wie echten Fließtext, d.h. der Umbruch wird der Breite des im Bericht dafür vorgesehenen Objekts angepaßt. In der folgenden Abbildung sehen Sie auch gleich noch eine Neuigkeit von Phoenix 5.0: die Preview-Funktion. Damit können Sie, ohne Papier für Testdrucke zu verschwenden, sehr schön Ihre Bericht-Definitionen überprüfen. In diesem Beispiel können Sie erkennen, wie der Inhalt des ersten Feldes je nach zur Verfügung stehendem Platz passend umbrochen wird (links und unten). Wollen Sie dagegen einen festen Umbruch, dann sollten Sie im Designer die Option "automatischer Wortumbruch" für das betreffende Textfeld abschalten. Nun übernimmt Phoenix exakt die Formatierung dieses Feldes in den Bericht - vorausgesetzt, das entsprechende Objekt ist hier groß genug. Das leidige Leerzeilen-Problem ... ... gehört nun der Vergangenheit an. Die Behandlung von Leerzeilen bzw. Feldinhalten mit unterschiedlicher Zeilenzahl ist hier genau so, wie man es möchte. Leerzeilen innerhalb eines mehrzeiligen Feldes werden jetzt also nicht mehr ignoriert (wie in der obigen Abbildung deutlich zu erkennen ist)! Für die Ausgabe von Feldern, deren Inhalt von Datensatz zu Datensatz eine andere Zeilenzahl ergibt, können Sie (wie bisher auch im Report) bestimmen, ob jeder Datensatz - unabhängig vom Inhalt der Felder - mit einer festen Länge gedruckt wird (ggf. also mit einem Leerraum aufgefüllt wird), oder ob die Datensätze nur mit der tatsächlich benötigten Anzahl Zeilen ausgegeben werden. Eine Option "Bereich zusammenhalten" sorgt außerdem automatisch dafür, daß nicht mitten in einem mehrzeilig ausgegebenen Datensatz ein Seitenumbruch erfolgt. Spezial-Tip Phoenix: Größe von Textfeldern Es ist in vielen Fällen ratsam, die Option "Breite/Höhe in Einheiten", besonders bei mehrzeiligen Textfeldern, nicht zu benutzen, da es sonst zu Darstellungsfehlern kommt, wenn man beim Schreiben über den unteren Rand hinauskommt. Außerdem ist dann keine Eingabe über den rechten Rand eines einzeiligen Eingabefeldes hinaus sowie kein horizontales Scrollen möglich. Diese Option ist also nur sinnvoll, wenn sicher ist, daß der Platz im Eingabefeld immer ausreicht (also z.B. bei Zahlen- oder Datumsfeldern), bzw. um die Abmessungen des Feldes pixelgenau bestimmen zu können. ### Phoenix und OLGA Mit OLGA - Oject Linking for GEM-Applications - hat Thomas Much ein sehr nützliches Verfahren entwickelt, das die Interaktion zwischen zwei Programmen auch auf TOS-Rechnern ermöglicht. Worum geht es? Manche Programme erlauben das Einbinden externer Dateien, ohne selbst diese Dateien bearbeiten zu können. In einer Phoenix-Anwendung beispielsweise lassen sich Vektor- oder Bitmap-Grafiken in einem speziellen Feldtyp anzeigen. Soll nun eines dieser Bilder geändert werden, muß man dazu ein Grafik-Programm starten, das Bild laden, bearbeiten und wieder speichern; danach muß in Phoenix dafür gesorgt werden, daß der betreffende Datensatz neu angezeigt wird. Mit OLGA und Phoenix 5.0 wird die Sache nun vereinfacht: ein Doppelklick auf die Grafik übergibt diese automatisch an das dafür angemeldete Programm; nach dem Sichern der geänderten Datei wird sie dann sofort in Phoenix aktualisiert. Im Designer ist das Bearbeiten einer Grafik in einer Maske auf die gleiche Weise möglich. Durch die Unterstützung von OLGA lassen sich nun auch endlich Texte "vernünftig" bearbeiten. Phoenix selber stellt in Textfeldern ja nur die allernötigsten Funktionen zur Verfügung; Blockfunktionen z.B. gibt es hier nicht. Über OLGA können Sie Texte nun an einen externen Editor übergeben: sie machen einen Doppelklick auf das Textfeld, und der Editor öffnet ein Fenster mit diesem Text. Nach dem Sichern des geänderten Textes erscheint dieser auch sofort in Phoenix. Programme, die OLGA als Server (also zum Bearbeiten von Dateien für eine andere Anwendung) direkt unterstützen, sind ArtWorx (für GEM-Metafiles), Papillon (für IMG-Bilder) und QED (für Text). Mit dem OLGAnisator von Thomas Künneth können Sie außerdem auch beliebige andere Anwendungen zum OLGA-Server machen. Somit sind Sie nicht auf QED angewiesen, wenn Ihr Lieblingseditor ein anderer ist. Der OLGA-Manager liegt als OLGAUSER.LZH in der MAUS Karlsruhe (0721-358887), der OLGAnisator als ONSTR1.LZH in der MAUS Nürnberg (0911-9407059). Hier noch ein wichtiger Hinweis: aufgrund eines Fehlers (Phoenix startet den OLGA-Manager nicht nach und erkennt ihn auch nicht, wenn er nach Phoenix gestartet wurde) funktioniert die Übergabe von Dateien per OLGA nur dann, wenn OLGA beim Start von Phoenix bereits im Speicher ist. ### Fazit zu Phoenix Phoenix 5.0 hinterläßt bei mir einen sehr zwiespältigen Eindruck. Einerseits wurden sehr gravierende Mängel immer noch nicht behoben (z.B. die fehlende Unterstützung des Klemmbretts oder von Drag&Drop), andererseits hat es im Bereich der Druckausgabe erhebliche Verbesserungen gegeben. Mit der neuen objektorientierten Berichtfunktion können im "Quasi-WYSIWYG-Verfahren" auf sehr einfache Weise ansprechende Ausdrucke erzielt werden. Zur hohen Qualität der Druckergebnisse trägt hier auch die langersehnte Unterstützung von Vektorfonts über NVDI bzw. SpeedoGDOS bei. Die Vielzahl der Optionen und Einstellungsmöglichkeiten läßt kaum noch Wünsche offen. Die Handhabung ist allerdings teilweise etwas umständlich; besonders die schlechte Bearbeitungsmöglichkeit von Texten empfinde ich als sehr störende Einschränkung. Schmerzlich vermißt wurde auch die Möglichkeit der Einbindung von Grafiken; dies ist aber für eine der nächsten Versionen noch vorgesehen. Die Möglichkeit des Zugriffes auf die Programmiersprache ist dagegen ein großer Pluspunkt. Durch die neue Berichtfunktion hat Phoenix - trotz der ansonsten immer noch vorhandenen Mängel - eine gewaltige Aufwertung erfahren. Besonders wer auf eine flexible und ästhetisch befriedigende Gestaltung der Druckausgabe Wert legt, sollte sich daher unbedingt die neue Version zulegen. Positiv hervorzuheben ist auch die vereinfachte Bearbeitung von Grafiken und Texten über das OLGA-Protokoll. Plus:
+ | Sehr mächtiger und flexibler Bericht-Generator
+ | Drucken über NVDI bzw. Speedo-GDOS
+ | Preview-Funktion
+ | Zugriff auf die Progammiersprache vom Bericht aus
+ | Unterstützung des OLGA-Protokolls in Grafik- und Textfeldern
+ | Desktop läßt sich jetzt in Fenster legen
+ | versionskompatibel in beide Richtungen seit mindestens v3.0
Minus:
- | Unterstützt immer noch nicht das GEM-Klemmbrett
- | Kein D&D, kein Iconify
- | Stark eingeschränkte Textbearbeitung im Bericht
- | kein Ausdruck von Grafiken
- | Sehr unpraktische Handhabung der Schrift-Einstellung
- | nur unvollständig implementiertes Undo
- | fehlerhafte Online-Hilfe
Martin Miethke
Copyright © by Rainer Wiesenfeller Letzte Änderung am 25. Juni 1997