StarBasic InTEAM - GUI-unabhängige Dialoge

GUI-unabhängige Dialoge

Einleitung

Da SD für das SO bei der Auswahl der Kontrollfelder die grösste gemeinsame Menge gewählt hat, ist zumindest diesem Punkt keine besondere Aufmerksamkeit zu schenken: was man im Dialog-Editor des SO bauen kann, das wird auch auf allen unterstützten Plattformen einigermassen so angezeigt. Doch der Teufel sitzt im Detail: plötzlich sieht der unter Windows 95 so wunderbar gestaltete Dialog auf einem Linux-Rechner kaum wiedererkennbar aus, und was im einen System noch sauber lesbar war, kommt auf dem anderen in krakeligster Schrift daher... Kaum besser ergeht es ihm unter OS/2: hier stören nicht die kleinen, sondern übergrosse Schriften das Bild....

Der hier wiedergegebene Dialog wurde auf einem Windows 95-System gestaltet. Alle Screenshots sind 1:1 wiedergegeben. Der erste zeigt zeigt ihn auf dem genannten Windows-Rechner. Der zweite, viel kleinere, stammt von einem Linux-System. Bei ihm geht nicht nur die nicht vorhandene Schrift im Titel verloren, sondern gleich auch noch ein grosser Teil des Bitmaps im Preview-Feld. Zudem ist der Rest der Texte derart klein geraten, dass sie sich kaum entziffern lassen. Zu guter letzt sind in der OS/2-Version die Schriften derart gross geraten, dass sie bei weitem nicht mehr im Dialog Platz haben. Die grösse des Fenster entspricht jedoch in etwa der Windows-Version.

Die kommenden beiden Abschnitte zeigen, wie sich diese Fallen umgehen lassen. Daraus resultiert zum Schluss ein Dialog, welcher sich mit minimalen Abstrichen gegenüber dem «Original» wohl auf den meisten Systemen sehen lassen kann. Die Beispieldialoge inklusive kurzer Erläuterung sind im SW-Dokument gui.sdw gespeichert.

Kontrollfeld-Schriften (Font)

Will man die unleserlichen Schriften auf anderen als dem Entwicklungs-System vermeiden, so gibt es eigentlich nur einen Hinweis: verwende keine Formatierung! Dass spezielle Schriften (also jene jenseits von Helvetica, Times und Plagiaten) Probleme bereiten, das ist nicht nur den Programmierern bekannt. Wer schon mal aus Versehen Druckerschriften verwendet hat und später den Drucker wechselte, kennt die Misère...

Leider ist es in StarBasic längst nicht damit getan, die Schriften einfach so zu belassen, wie sie sind. Ganz im Gegenteil müssen selbst die vom System vorgegebenen Einstellungen erst gelöscht werden, um plattformunabhängig zu sein! Es ist also wichtig, dass im Schriftauswahl-Dialog überhaupt keine Einstellung vorhanden ist:

So wie hier in der Linux-Version sind im Font-Dialog sämtliche Einträge zu löschen. Dies scheint das StarOffice zu veranlassen, beim Anzeigen selbständig die jeweils Plattform-spezifischen Standard-Schriften zu verwenden. Dies ist beispielsweise auf Windows-Systemen die «MS Sans Serif», unter Linux «Helvetica».

Dennoch ist es manchmal wünschenswert, Formatierungen anbringen zu können. So etwa im eingangs gezeigten «AutoPilot»: ein fetter Titel soll den Dialog zieren. Hierbei ist darauf zu achten, dass der Font (im obigen Dialog «Art» genannt...) nicht festgelegt wird, sondern nur seine Auszeichnung, also etwa den Schnitt «Fett Kursiv» und die Grösse 16 Punkt. Es wird dann wiederum die Standard-Schrift verwendet, dieses Mal aber unter Berücksichtigung der gewünschten Attribute.

Achtung: da die Systemschriftarten auf manchen Systemen nicht skalierbare Bitmap-Fonts sind, empfiehlt es sich, die Einstellungen auszuprobieren. Ansonsten kann es bei Verwendung nicht vorliegender Schriftgrössen zu unschönen Treppeneffekten kommen!

Dialog-Geometrie (AutoAdjustSize)

Ein weiteres unschönes Problem stellt die verzerrte Geometrie der Dialoge, abhängig vom verwendeten Betriebssystem, dar. Wo das Problem genau liegt, weiss ich nicht. O-Ton eines SD-Entwicklers: «Windows vergrößert immer alles von sich aus, [...] X macht sowas nicht.». Na ja, als StarBasic-Entwickler muss man halt damit leben. Doch die StarDivisionäre haben hier gute Arbeit geleistet: das Setzen der Eigenschaft AutoAdjustSize für den Dialog sorgt schon mal für dessen anständige Skalierung. Es ist also in jedem Fall zu empfehlen, diese auf den Wert True zu setzen!

Leider hat bei dieser Arbeit die Entwurfs-Ansicht eines Dialoges nicht immer viel mit dem Resultat gemein: nebenstehender Screenshot vom Linux-System entspricht dem unveränderten Beispiel von oben...

Skalierung der Preview

Soll das Bild im Preview nicht einfach an der rechten oberen Ecke klebend abgebildet werden, dann wird's komplex. Ebenso wie der gesamte Dialog unterliegt natürlich auch das Preview-Feld der erwähnten Skalierung. Dies führt eine ganze Menge Probleme mit diesem Kontrollfeld mit sich. Die suboptimale Plazierung eines Bitmaps ist nur der Anfang... Sollen auch noch eigene graphische Elemente darauf abgebildet werden (siehe «Kurzeinführung Preview»), so kommt man nicht umhin, sich mit einigen undokumentierten Befehlen auseinanderzusetzen :-/. Dies soll detailliert im «Exkurs: Preview plattformunabhängig» geschehen.

Will man nur einmal ein Bild in der Preview darstellen, so kann man die ganze Twips-Geschichte erst mal vergessen: in der tools.sbl liefert SD nämlich eine schöne Methode mit, mit welcher sich diese Darstellung ungemein vereinfachen lässt. Die Methode nennt sich PaintPicOnPreview:

PaintPicOnPreview(Preview As Object, _
                  ByVal Filename$, _
                  ByVal Width%, _
                  ByVal Height%, _
                  ByVal bDrawFrame%)

Als erster Parameter muss eine Referenz auf das Preview-Feld übergeben werden («MyDialog.MyPreview»). Danach folgt der vollständige Pfad zur gewünschten Graphikdatei (Achtung: nur .BMP werden akzeptiert!), dessen Breite und Höhe, sowie ein boole'scher Wert, ob die Abbildung von einem schwarzen Rahmen umgeben werden soll (True) oder nicht (False). Daraus ergibt sich in etwa eine Routine wie folgt, die mit dem Ereignis OnPaint des Preview verbunden werden muss:

Sub MyPreview_OnPaint()
   PaintPicOnPreview(MyDialog.MyPreview, _
      "file:///d|/daten/nicepic.bmp", 150, 250, False)
End Sub

Die Routine PaintPicOnPreview sorgt dann selbständig dafür, dass das Bild korrekt skaliert und allenfalls im zu grossen Preview zentriert dargestellt wird.

Achtung: weder PaintPicOnPreview noch die darin verwendeten Funktionen sind öffentlich dokumentiert! Es ist also nicht garantiert, dass diese in einer zukünftigen Version noch funktionieren. Doch ich bin zuversichtlich ;-).

Zusammenfassung

Berücksichtigt man die beschriebenen Punkte, so lässt sich auch der eingangs gezeigte Dialog so weit anpassen, dass er, wenn auch unter Verlust der ursprünglich im Titel verwendeten Schrift, auf den verwendeten Plattformen recht einheitlich in Erscheinung tritt.

Während sich also die Windows 95-Version unseres Beispiels kaum vom ursprünglichen Dialog unterscheidet, haben die übrigen Versionen doch ganz erheblich an Qualität gewonnen: das Preview-Feld zeigt das ganze Bitmap an und die Schriften sind gut lesbar. Und auch das nicht unproblematische Windows NT 3.51 stellt den Dialog sauber dar.

Wer plattformunabhängige Dialoge entwickeln will, der kann sich glücklich wähnen, wenn er Zugang zu den verschiedenen Systemen hat. Während Probleme etwa mit Pfaden oder Gerätezugriffen noch mit Denkarbeit und Kontakt zu Anwendern auf anderen Betriebssystemen gelöst werden können, ist bei den Dialogen oftmals etwas Ausprobieren angesagt. Der dann aber noch minimale Aufwand lohnt sich meines Erachtens unbedingt, wenn man ansehnliche Programme abliefern will!