Lange erwartet, jetzt endlich erhältlich: mit faceVALUE ist visuelle Basic-Programmierung auch für den Atari verfügbar.

Zum Test lag die Version 2.1 vor, die sich von der Verkaufsversion nur in der noch nicht ganz vollständigen Dokumentation unterscheidet. Die Struktur der Anleitung lag jedoch bereits vor.

Seit dem mittlerweile legendären NeXT-Computern ist visuelle Programmierung groß in Mode. Programme werden nicht mehr nur programmiert, sondern erst einmal "zusammengesetzt". Die Verwaltung der einzelnen Module übernimmt dabei das generierte Programm, man muß nur noch auf entsprechende Ereignisse reagieren.
faceVALUE (kurz: FV) ist - neben dem ACS für Pure C/Pascal -, eine Umsetzung dieses Konzept für GFA-Basic. Der größte Unterschied ist der, daß faceVALUE nicht aus einem Guß ist, wie z.B. Visual Basic. Das bedeutet, das ein Resource-Editor und natürlich GFA-Basic benötigt wird. Mit den v1.0 und 1.1 wurde dieses Konzept bereits gut umgesetzt. Nach einer langen Durststrecke und vielen Ankündigungen gibt es jetzt v2.1. Da man über FV mittlerweile ein ganzes Buch schreiben könnte, bleibe ich weitgehend bei den Neuheiten. Für denjenigen, der FV noch nicht kennt, sind die GFA-Basic-Hypertexte empfehlenswert. Ebenso ist eine Demoversion von FV angekündigt.

faceVALUE 2 bringt einige änderungen mit sich und so müssen die alten Resourcen erst angepaßt werden. Dies nimmt jedoch nur wenig Zeit in Anspruch.
Bei Dialogen muß der Erweiterte Typ für den Dialoghintergrund auf 18 gesetzt werden. Dies war in v1.1 nur eine Empfehlung, in 2.1 ist dies Pflicht. Ein anderer Wert wäre vielleicht sinnvoller gewesen, da Geneva so in jeden Dialog einen Checkbutton hineinzeichnet. Die zweite änderung betrifft den "System"-Dialog: neben dem langen Programmnamen, der Version und dem Autor kann dort auch ein kurzer (also max. 8 Zeichen langer) Dateiname gesetzt werden. Diese kleine änderung ist beim Testen des Programms äußerst nützlich, denn beim Testen im Interpreter war das eigene Programm bisher nur mit "GFABASIC" von anderen Anwendungen ansprechbar.

Da sich nicht bei jeder änderung alle Prozeduren ändern, bietet FV die Möglichkeit, eine Update-Datei zu erstellen, die ale änderungen beinhaltet. Erfreulicherweise ist diese Funktion deutlich intelligenter geworden, denn zu meiner šberraschung fing FV an, sogar die GFA-Datei einzulesen und diese zu aktualisieren. In den selbstgeschriebenen Prozeduren verändert FV natürlich nichts und in dem Teil, in dem das Programm auf Eingaben und Mausklicks reagiert, werden die änderungen von FV kommentiert. Es geht also nichts verloren, dafür reduziert sich die Anpassungsarbeit wesentlich. Die aktualisierte Datei überschreibt das Original übrigens nicht. Anders verhält es sich allerdings, wenn Sie änderungen an den FV-System-Routinen oder den Wrinkels vornehmen - diese änderungen werden ohne Prüfung überschrieben.

Im FV-Programm kann (fast) jeder Dialog getestet werden. Dadurch erkennt man schon vorher, ob alle Resource-Flags richtig gesetzt wurden. Wünschenswert wäre nur noch das FV den Namen des Objektes anzeigt, das betätigt wird.
Die Test-Funktion stürzt übrigens ab, wenn in dem Dialog Farbicons vorkommen.

Vom Hauptdialog aus können jetzt alle relevanten Einstellungen getätigt werden. Neu ist die Möglichkeit, verschiedene Hypertexte anzusteuern. Das Popup zur Auswahl des Hypertextes kann auch "abgerissen" werden und liegt dann als eigenes Fenster vor.

Die BubbleGEM-Hilfe ist normalerweise eine nützliche Sache und mit dem zeitgesteuerten Erscheinen der Sprechblase fällt auch das Drücken der rechten Maustaste weg. Unter FV kann man damit aber nicht mehr vernünftig arbeiten, was natürlich nicht die Schuld von BubbleGEM ist. Das zu einigen Objekten eine Hilfe erscheint, ist nützlich, aber selbst für den Fensterhintergrund und die Fensterbedienelemente erscheint eine Blase. Den Text "There is no help available for this object." wird man so recht häufig sehen. Auch die Testfunktion ist davon betroffen, nur erscheint dort ständig "No bubble help for objects in an external dialog" - logisch, denn woher soll FV den Hilfstext auch nehmen?
Die einzige Abhilfemaßnahme ist, den Hilfsdämon im BubbleGEM-CPX vorübergehend auszuschalten.

FV lässt sich komplett über GEMScript steuern, Script-Fans können also einige Arbeitsabläufe automatisieren. Bei den Steuerkommandos hätte sich FV aber gerne an den Standardkommandos orientieren können, es verwendet z.B. "OPEN_RSC" statt "OPEN". Zumindest optional sollten die Standardkommandos integriert werden, damit man FV mit den gleichen Kommandos ansteuern kann, wie andere GEMScript-Programme auch.

Natürlich gbt es mit dieser Version eine Reihe neuer Objekte, die größtenteils schon von anderen Systemen bekannt sind. Ob man von den Neuerungen gebrauch macht, bleibt jedem selbst überlassen, denn einige gehören eher in die Kategorie "Spielerei".

Der Desktop kann jetzt so ziemlich jeden Objekttyp aufnehmen. Abgesehen davon, daß diese in Zeiten von Multitaskingsystemen nicht benutzt werden sollten, wird der Benutzer dadurch auch noch mehr verwirrt, wenn sich plötzlich ein Popup-Menü auf dem Desktop befindet. Interessanterweise ist dies praktisch eine Umsetzung des Active Desktops von Microsoft, denn unter Windows98 gibt es auch die Möglichkeit, Webseite inklusive Formularen als Desktop zu benutzen und so einen Pentium wieder zum 386er zu degradieren. Die faceVALUE-Lösung ist übrigens deutlich schneller...

Das was mit Geneva bei Menüs machbar ist, klappt bei faceVALUE jetzt auch mit Popups. Tear-Off-Popus müssen als extra-Objekt-Bäume vorliegen und werden etwas anders angesprochen. Die Verwaltung unterscheidet sich aber nicht von den herkömmlichen Popups. Da es bei FV keine Mischung aus Listboxen und Popups gibt, sind dynamische, d.h. während des Programmablaufs erweiterbare, Tear-Off-Popups nicht möglich.

Noch flexibler sind die animierten Icons geworden, denn Sie können nun von einer Seite zur anderen Laufen, ab einem bestimmten Frame gestoppt werden ... Nicht mehr zeitgemäß ist jedoch die Einschränkung, nur Images benutzen zu können, denn Farbicons gehören mittlerweile zum Standardrepartoi jeder GEM-Library. Dadurch wirken FV-Programme alle ziemlich farblos. Programme wie der HomePage Pinguin benutzen zwar Farbicons, aber dies wird in keinster Weise von FV unterstützt, so das in der Resource entweder zwei Icons (s/w und Farbe) oder gleich zwei Resourcedateien erstellt werden müßen. Aber auch diese beiden Lösungen haben ihre Grenzen: Farbicons in Alert-Boxen oder in Image-Popups sind nicht möglich.
Daher hat mich auch die Möglichkeit, animierte Buttons zu erzeugen, nicht beeindruckt, denn die Image-Farbe plus dem Dialog-Hintergrund sieht nicht sehr attraktiv aus.

Neu sind Drag & Drop-Objekte, die über ein internes Protokoll gehandhabt werden. Auch hier ist die Anwendung erfreulich einfach: Zwei Bits gesetzt und schon ist das Objekt Drag & Drop fähig!
ähnlich funktionieren auch bewegbare Objekte, nur sind sie von durch das Parent-Objekt in ihrem Freiraum eingeschränkt.
Die Einsatzmöglichkeiten dieser beiden Objekte sind vielfältig; neben dem in der Anleitung erwähnten Desktop könnte man damit auch Spiele oder eine frei konfigurierbare Toolbar realisieren.

Eines der Objekttypen, die ich in FV 1.1 vermißte, sind die offenen Listboxen. Zwar bedeuten sie keinen Zuwachs an Funktionalität, aber in bestimmten Fällen können sie die šbersichtlichkeit steigern. So ist eine Fontauswahl mit offenen Listboxen sinnvoller, da mehr Optionen auf einmal sichtbar sind. Sie sind jedoch nicht tastaturbedienbar und es gibt leider keinen horizontalen Verschiebebalken.
Die deselektierte Darstellung von einzelnen Einträgen ist mit offenen Listboxen noch nicht möglich.

Listboxen sind jetzt mit einem Autolocator ausgerüstet, was natürlich erst ab einer bestimmten Größe Sinn macht. Außerdem können Einträge gezielt deselektiert dargestellt werden, indem man ihnen ein "##" voranstellt.
Die Größe der Box ist immer noch an die Größe des Parentobjektes gebunden. Dies gilt leider auch für die Menülistboxen, womit es leider keine Auswahlbox gibt, die Größe und Inhalt während des Programmablaufs ändern kann.

Normale Buttons können nur zwei Zustände annehmen, was für die meisten Fälle ausreicht. Auf anderen Betriebssystem sind jedoch Tristate Buttons sehr beliebt, wobei der zusätzliche Zustand oft für "nicht ändern" steht. ähnliches ist jetzt auch mit FV möglich - es wird für jeden Zustand ein eigenes Image abgelegt. Dadurch ist auch ein anderer Look für Check- und Radiobuttons möglich, aber Vorsicht ist angebracht, da dies eine größere Einarbeitungszeit zur Folge haben könnte.

Edit-Objekte können durch das Setzen eines Bits zu Callback-Objekten gemacht werden. Nach jedem Tastendruck wird eine entsprechende Nachricht übermittelt, der Variablenwert hat sich jedoch bereits geändert. Trotzdem hat man dadurch zumindest die Möglichkeit, eigene Eingabemasken zu realisieren, auch wenn eine Möglichkeit, diese Maske schon vorher zu definieren, nicht schlecht wäre.

Mit dem Resizer-Objekt kann ein Dialog vergrößert oder verkleinert werden. Ein Dialog wird damit einem normalen Fenster ähnlicher, sieht man einmal von den fehlenden Scrollbalken ab.

änderungen gibt es bei FV auch bei den Fenstern:

Neu hinzugekommen sind Dialoge ohne Fensterattribute, womit jetzt eigentlich alle möglichen Fenstertypen abgedeckt sein müßten.

Dieser Fenstertyp ist nicht mehr ganz so modal, wie es der Name verspricht. Normalerweise sollte dieser Fenstertyp den Rest des Programms anhalten, solange er sichtbar ist. Menütitel sollten also gesperrt und andere Dialoge können nicht geschlossen werden. Letzteres ist allerdings nicht der Fall, denn Dialoge, die unter dem modalen Dialog liegen können nach wie vor geschlossen werden. Das fatale ist, daß das Programm damit natürlich nicht rechnet, denn sonst hätte es wohl kaum einen modalen Dialog geöffnet.

Ein faltbarer Dialog eröffnet seine ganzen Möglichkeiten erst, wenn man auf den Fuller klickt. Zurückfalten ist nicht möglich.

Die Extra-Routinen, die FV beiliegen sind zahlreich und lassen sich kaum alle adequat beschreiben.
Exemplarisch seien die Routinen für GEMScript und BubbleGEM erwähnt.

Die entsprechende Routine ist zum Empfangen von Kommandos geeignet und bindet eine eigene Prozedur ein, in der auf eintreffende Nachrichten reagiert wird. Man sollte dabei dann nicht unbedingt dem Beispiel von FV folgen und Standardkommandos abändern. Sind erstmal ein paar Kommandos eingebaut, kann das eigene Programm von anderen herumkommandiert werden.
Natürlich ist der entgegengesetzte Weg auch schön, denn man kann andere Programme zu Plugins machen. Die Routine ist jedoch nicht zum Versenden von Kommandos gedacht. Trotzdem kann relativ einfach aus den vorhanden Routinen eine Routine zum Versenden von Kommandos geschrieben werden - schließlich werden nur die Rollen vertauscht.

ähnlich funktioniert auch das Ansteuern von BubbleGEM: Eine zusätzliche Prozedur wird eingebunden, in der für jedes Objekt ein String für BubbleGEM zurückgeliefert wird. Diese Routinen unterstützen bereits das zeitversetzte Erscheinen der Hilfsblasen.
Beim Test brach das Programm jedoch mit einer Fehlermeldung ab. Der Fehler war schnell lokalisiert und liegt in der Datei DATA\LIB\BUBBLE.LST. Einer Word-Variable wird nämlich der Wert &HBABB (47803) zugewiesen - Word-Variablen haben in GFA aber nur einen Wertebereich von -32768 bis 32768. Sollte der Fehler bei Ihnen nicht schon behoben sein, so kann dies leicht selbst gemacht werden: &HBABB ist durch WORD(&HBABB) zu ersetzen - dann funktioniert es ohne Probleme.

Bei dem Namen dachte ich zumindest erst an nasse Handtücher, was zwar nicht die tatsächliche Bedeutung ist, aber im Adams'schen Sinne auf die Nützlichkeit durchaus zutrifft. Wrinkles sind so etwas wie Extra-Routinen mit erweiterten Einflußmöglichkeiten. In der Wrinkle-Datei kann festgelegt werden, in welche FV-Prozeduren Programmcode eingefügt werden soll. Beispielwrinkles (darunter Minesweeper und ein Puzzle) liegen dem Programm bei, ebenso eine Erläuterung zum Erstellen von eigenen Wrinkles.

Nicht unerwähnt bleiben sollen die vielen Bugfixes, die an FV2 vorgenommen wurden. Damit generierte Programme waren wesentlich stabiler als mit FV1.1 oder den Vorversion (Betas) von FV2. Dies wird natürlich auch die Anwender von mit faceVALUE erstellten Programmen freuen, denn alle FV2-Programme profitieren davon. Kurzgesagt: Schon wegen dieser Bugfixes sollte man auf FV2.1 wechseln.

Was für die Zukunft in FV2.1 geplant ist, steht zwar noch in den Sternen, aber in der Doku werden einige Punkte aus der "to-do-Liste" des faceVALUE-Teams verraten. So soll man nicht mehr mit dem Window-Handle und -Array konfrontiert werden. Außerdem ist geplant, das Verwenden eines Menübaums optional zu machen. Damit würde auch der "Alibi-Menübaum" bei kleineren Programmen wegfallen.

Neben den schon im Artikel erwähnten Kritikpunkten gibt es einige Dinge, die ich gerne in einer der nächsten Versionen sehen würde. So wären die sogenannten Dialogkarten, mit der sich ein Dialog in verschiedene Felder einteilen lässt, nicht schlecht. Ein Beispiel, wie sinnvoll so etwas ist, ist Texel, wo die Dialoge dadurch sehr übersichtlich werden.
Auch der 3D-Look könnte verbessert werden, denn er entspricht immer noch dem der GFA-Flydials.
Am wichtigsten fände ich aber die Beseitigung der 64K-Grenze für Resource-Dateien, denn diese Einschränkung disqualifiert FV für größere Programmierprojekte - ich kann z.B. mein Dr.Who-Quiz mit FV2.1 gar nicht mehr bearbeiten, da auch die Version mit s/w Icons schon über 64 KB groß ist, von der Farb-Version mit 560 KB ganz zu schweigen... Ansonsten bleibt die Programmweiterentwicklung irgendwann an dieser antiquierten Grenze liegen.

Die Vertriebsform von faceVALUE ist zwar weiterhin Löhnware, aber der Vertrieb selber hat sich geändert: Holger Herzog vertreibt jetzt das Programm direkt. Ein Nachteil war nicht zu bemerken, denn mein faceVALUE kam recht schnell an.

faceVALUE ist für GFA-Programmierer ein Muß und hat einige Features, die auch Benutzer anderer Programmiersprachen vor Neid erblassen lassen müßten. Trotz einiger vorhandener Bugs ist es wichtig, daß die neue Version jetzt verfügbar ist, denn sie ist ein deutliches Lebenszeichen für das GFA-Basic. Der Innovationsfaktor kann nur unzureichend in diesem Test zum Ausdruck gebracht werden, denn der Zeitvorteil den die (wenn auch nur teilweise) visuelle Programmierung gegenüber herkömmlichen GEM-Libraries bringt ist nicht zu unterschätzen. Der unschlagbare Preis, der wohl kaum die Arbeit vergütet, die die Programmierer in faceVALUE gesteckt haben, sollte honoriert werden - indem man das Programm kauft und viele GFA-Programme damit schreibt.

• Positiv:
  • große Auswahl an nützlichen Routinen
  • saubere GEM-Programme
  • Update-Funktion
  • Testen von Dialogen
  • neue Objekte
  • Unterstützung von BubbeGEM
  • Wrinkels
  • unschlagbarer Preis
• Negativ:
  • keine RSC-Dateien größer 64 KB
  • keine Farbicons
  • nicht-modale Dialoge nicht wirklich nicht-modal
  • nervige BubbleGEM-Hilfe im FV-Hauptprogramm

Matthias Jaap

Kontakt Artikel-Archiv