Liste mit FileMaker Versionen

Liste mit FileMaker-Versionen

Dateiformate und Versionen


24. Oktober 2023In TippsBy Karsten Risseeuw1 Minutes

Dateiversionen

FileMaker gibt es seit über 30 Jahren. Im Laufe dieser langen Zeit gab es verschiedene Dateiformate. Dazu zählen

  • fp4
  • fp7
  • fmp12

Diese Dateiformate wurden mit der entsprechenden Version (4, 7, 12) eingeführt und werden so lange beibehalten, bis ein neues Format eingeführt wird. Das Format .fmp12 gilt demnach seit FileMaker Pro 12 (April 2012) bis heute (FileMaker Pro 2023).

FileMaker Pro Versionen

Das Dateiformat ist wichtig, aber FileMaker selbst wird auch aktualisiert. Jede neue FileMaker Version erhält bislang unbekannte Funktionen. FileMaker Pro 12 und FileMaker Pro 2023 benutzen zwar dasselbe Dateiformat, aber aktuelle Versionen unterstützen wesentlich mehr Funktionen. Es kann demnach notwendig sein, eine aktuelle Version von FileMaker zu beschaffen, wenn man neuere Funktionen nutzen will.

Liste mit FileMaker Versionen

Auf der Website des Herstellers Claris findet man eine stets aktuelle Liste mit FileMaker Versionen und allen Neuerungen.

Liste mit FileMaker Pro Versionen

Liste auf Wikipedia

Auf einer Wikipedia-Seite findet man die komplette Liste aller FileMaker-Versionen mit den dazugehörenden Dateiformaten.

FileMaker auf Wikipedia

Deutschsprachiger FileMaker Newsletter

Deutschsprachiger FileMaker Newsletter

Direkt auf filemaker-kompetenz.ch abonnieren


29. Juli 2023In Allgemein, TippsBy Karsten Risseeuw1 Minutes

Für FileMaker gibt es nur wenige Newsletter. Die Informationsseiten stammen häufig von aktiven Entwicklern oder grösseren Communities. Jeder Beitrag ist eine Bereicherung, aber gibt es so etwas wie einen FileMaker Newsletter für deutschsprachige Entwickler?

FM Starter Newsletter

Auf dieser Website kann man sich für einen Newsletter abonnieren. Der eigene Newsletter richtet sich selbstverständlich auf eigene Produkte, welche über fmstarter.com angeboten werden. Dieser Newsletter wird nur selten verschickt. Wir sind eher dazu übergegangen, Nachrichten sehr spezifisch zu versenden. Das heisst etwa, dass jemand, der ein Add-on angefragt hat, eine Information bekommt, wenn ein neues Add-on auf der Website erscheint, oder jemand, der FM Starter erworben hat, der wird über neue Versionen informiert.

Dieser Newsletter ist jedoch keine allgemeine Informationsquelle für FileMaker Themen. Das will und soll es gar nicht sein. Der FM Starter Newsletter erscheint in Deutsch und Englisch.

FM Starter Newsletter

FileMaker-Newsletter von filemaker-kompetenz.ch

Es gibt ein allgemeiner und deutschsprachiger FileMaker Newsletter via der Website filemaker-kompetenz.ch. Diese Website entsprang einer lokalen FileMaker-Entwicklergemeinde und verlinkt Entwickler aus der Schweiz, Deutschland, Österreich und Liechtenstein. Monatlich gibt es eine Zusammenfassung der neuesten Beiträge.

Am besten, man schaut sich diese Seite einmal an:

filemaker-kompetenz.ch

Berechne-Funktion kann kann eine FileMaker-Anwendung beschleunigen

Berechne-Funktion kann kann eine FileMaker-Anwendung beschleunigen

Ersetze Berechnungsfelder mit regulären Text- oder Nummernfeldern


1. September 2022In TippsBy Karsten Risseeuw9 Minutes

Die «Berechne» Funktion in FileMaker führt eine Berechnung aus, als wäre es ein Berechnungsfeld. Eine Berechne-Funktion verwendet aber kein Berechnungsfeld, sondern stattdessen reguläre Text- oder Nummernfelder. Diese können indexiert werden, was zu einer besseren Performance führt.

Berechnungsfelder verlangsamen

Warum sollte man statt ein Berechnungsfeld normale Text- oder Nummernfelder verwenden? Ein wichtiger Grund kann in der Indexierung liegen.

Berechnungsfelder werden stets aktualisiert und können deshalb nicht indexiert werden. Felder, die stets aktualisiert werden, verlangsamen jede FileMaker Lösung. Das macht sich insbesondere bei grossen Datenmengen in Listenansichten bemerkbar, sowie bei Scripts, die auf Layouts zugreifen müssen, worin Berechnungsfeldern liegen.

Normale Text- und Nummernfeldern dagegen werden meist automatisch indexiert und können deshalb schnell Resultate liefern – es muss nichts mehr berechnet werden. Es ist sinnvoll, Berechnungen in normalen Text- und Nummernfeldern auszulösen, aber nur im Bedarfsfall. Grösstenteils müssen Angaben nur einmal berechnet werden und vielleicht später noch einmal in einer Korrektur. Mehrheitlich ist eine ständige Neuberechnung nicht erforderlich und belastet das System nur unnötig.

Will man performante Lösungen erstellen, sind Berechnungsfelder häufig ein Flaschenhals. Deswegen kann es sich lohnen nach Alternativen Ausschau zu halten.

Berechne den Text

Texte können zusammengebaut werden. Ein typisches Anwendungsgebiet sind Adressblöcke. Man kann etwa eine Adresstabelle mit folgenden Feldern haben:

<Firma>
<Strasse>
<Postleitzahl> <Ort>.

Dies ist nur ein vereinfachtes Beispiel. Die meisten Adressen sind deutlich komplexer. Damit man diese Angaben nicht ständig neu zusammensetzen muss, kann es sinnvoll sein, ein separates Feld für eine <Komplettanschrift> zu erstellen. Darin kann man die gesamte Adresse abbilden. Bei Briefen, Rechnungen und dergleichen muss man nur auf das vorberechnete Feld der <Komplettanschrift> verweisen. Weil das berechnete Feld ein normales Textfeld ist, kann dieses Feld indexiert werden. Es geht in diesem Beispiel um das Prinzip, nicht um diese spezielle Lösung, welche als Beispiel herbeigezogen wird.

Das Resultat soll in das neutrale Textfeld <Komplettanschrift> geschrieben werden. Es gibt mehrere Optionen, dies zu lösen:

  1. Per Script (Feldwert setzen + Berechnung im Script)
  2. Per Felddefinition (Definition im Feld selbst)
  3. Per Felddefinition (Definition in einem externen Referenzfeld)

Die Berechnung findet also nur 1x statt. Sie sollte aber bei Bedarf wiederholt werden können.

Hier liegen nun die Unterschiede zu einem Berechnungsfeld: Bei einem regulären Text- oder Nummernfeld muss man die Berechnung speziell auslösen, während bei einem Berechnungsfeld ständig aktualisiert wird. Daraus folgt selbstverständlich, dass die Entwicklung mit regulären Feldern etwas aufwändiger ist. Die Belohnung liegt jedoch in einer performanteren Lösung und steuerbaren Resultaten.

Links sind verschiedene Adressfelder. Rechts steht das Feld <Komplettanschrift>, worin die Daten zusammengerechnet wurden. Das Feld rechts ist kein Berechnungsfeld, sondern ein normales Textfeld.

Berechnung per Script

Eine einfache Möglichkeit, ein berechneter Wert in ein reguläres Feld einzufügen, ist mit einem Scriptschritt:

Berechnung im Feld

Eine weitere, ressourcenschonende Methode ist die Verwendung eines Textfeldes, worin man eine Berechnung angibt:

Die Berechnung wird bei Änderung der Datenfelder jeweils neu aktiviert. Danach ist wieder Funkstille bei den Berechnungen. Die Belastung des Systems ist minimal und das Resultat kann indexiert werden.

3. Berechnung mit «Berechne» Funktion

Die automatische Berechnung bei der Texteingabe (Beispiel 2) funktioniert gut. Sie funktioniert jedoch nicht immer. Speziell mit externen Referenzen kann die «automatische» Neuberechnung hapern. Das ist logisch, denn eine Berechnung in einem regulären Textfeld muss immer speziell getriggert werden.

Folgendes Szenario könnte zutreffen: Statt eine Berechnungsformel in einem Feld oder in einem Script zu verstecken, kann ich die Formel offen in einem Textfeld ablegen. Das ist dann die Definition für eine Berechnung, nicht die Berechnung selbst. Dort, wo ich das Resultat der Berechnung sehen will, muss ich die Berechnung herbeiziehen, dann evaluieren und das Resultat in das Resultatfeld schreiben.

Werden nun Textdefinitionen als «Text» übergeben, sind diese nicht automatisch evaluiert. Hier kommt die Berechne-Funktion zum Einsatz.

  • Im Feld, wo ich ein Resultat sehen will (z.B. <Komplettanschrift>), erstelle ich ein Verweis auf eine externe Berechnungsformel, die in einem Textfeld liegt. Diese externe Formel soll mir die Berechnung im Feld auslösen:
    • Felddefinition <Komplettanschrift> hat bei der «Eingabe» eine «Formel», worin ich das externe Feld angebe: [ Externe Definition ]
    • Diese Berechnung wird leider nicht automatisch ausgeführt. Das korrigiert man mit der Berechne-Funktion: Berechne ( [ Externe Definition ] )
  • Steuern kann man die Berechnung mit einem Trigger-Feld. Ein Trigger-Feld sagt, wann die Berechnung ausgeführt werden soll. Eine Änderung im Trigger-Feld bewirkt dies. Das funktioniert wie folgt:
    • Berechne ( [ Externe Definition ] ; [ Trigger-Feld ] )
    • Trigger-Felder aktivieren durch Änderung des Inhaltes die Evaluation.

Hier liegt die Berechnung für zwei verschiedene Adressblöcke in normalen Textfeldern. Es sind komplexe Berechnungen. Beachte: In diesen Feldern liegt nur die Formel. Berechnet wird hier nichts. Das Ziel ist es jedoch, die Berechnung zentral abzulegen und an einem anderen Ort zu evaluieren.

Hier ist das eigentliche Feld für das Resultat der Berechnung. Es ist jedoch kein Berechnungsfeld. Die Berechnung wird «Bei Dateneingabe» ausgeführt, was sich in den Einstellungen des Feldes definieren lässt. Dort wird der Verweis auf die vorher genannte Formel mit «Berechne ( FORMELFELD)» ausgelöst. Wegen der Komplexität reicht das jedoch nicht. Die Berechnung hat häufig nicht automatisch funktioniert. Ein extra Trigger muss dies beheben. Deswegen steht hier «Berechne ( FORMELFELD ; TRIGGERFELD )».

Mehrere Trigger für die Berechne-Funktion

Die Berechne-Funktion unterstützt nur 1 Trigger. Das ist eine Begrenzung. Es funktioniert recht einfach: Ändert sich der Inhalt des Trigger-Feldes, dann wird die Berechnung ausgeführt. Bei komplexen, verschachtelten Berechnungen und bei externen Feldern kann die Berechnung stocken. Ein Trigger kann sie aber gezielt wieder zum Laufen bringen. Das ist die Aufgabe des Triggers.

Nur 1 Trigger steht zur Verfügung. Manchmal stehen aber mehrere Felder in einer Berechnung, worauf die Berechne-Funktion nicht wirkt. Diese Felder kann man in ein neues Feld zusammenrechnen (addieren!), damit daraus ein Wert entsteht. Ändert sich nun in einem der addierten Felder etwas, dann ändert sich auch die Summe im separaten Trigger. Das separate Feld wird also nur angelegt, damit eine sonst nicht entdeckte Änderung trotzdem zu einer Neuberechnung führt. Es ist ein Hilfsfeld.

Als Triggerfeld habe ich ein Nummernfeld angelegt, worin ich die relevanten Schalter für diese Berechnung «zusammengezählt» habe. Das Ergebnis ist nicht wichtig. Es wird jedoch zuverlässig jede Änderung in den Schalter-Feldern berücksichtigen. Die Änderung triggert nun die Berechnung der <Komplettanschrift>.

Einsatzgebiete

Lösungen wie diese helfen dabei, eine Anwendung zu optimieren. Das einzige Ziel dabei ist es, Berechnungsfelder zu vermeiden, weil die ständig Ressourcen benötigen. Reguläre Textfelder dagegen können indexiert werden. Die Techniken in diesem Beitrag zeigen, wie man eine Berechnung bei Bedarf in einem regulären Textfeld triggert.

Beispiel

Im folgenden kurzen Video wird das Ergebnis des letzten Beispiels gezeigt. Die Adresse rechts im Bild wird mit verschiedenen Schaltern formatiert. Das Ergebnis wird in ein reguläres Textfeld gespeichert. Das Beispiel zeigt, wie man mit regulären Feldern Berechnungen ganz ohne Berechnungsfelder bei Bedarf ausführen kann.


Das KISS-Prinzip in der FileMaker Entwicklung

Das KISS-Prinzip in der FileMaker Entwicklung

Einfacher ist besser


6. Mai 2022In TippsBy Karsten Risseeuw10 Minutes

Softwareentwicklung ist komplex. Die Komplexität einer Aufgabe zu bewältigen, ist bestimmt eine wichtige Herausforderung für jeden Entwickler. Hat man die Komplexität jedoch einmal bewältigt, geht es anschliessend um die Vereinfachung. Dieser Beitrag ist eine persönliche Reflexion über die Entwicklung hin zu grösserer Vereinfachung und was man sich dabei vorstellen kann.

Das KISS-Prinzip

Anfangs der 1960er-Jahren wurde von der amerikanischen Navy ein Grundsatz für gutes Design geprägt. Unter dem Akronym «KISS» verbirgt sich die Idee, alles möglichst einfach zu halten. KISS steht für

  • Keep it simple, stupid
  • Keep it simple & smart
  • Keep it simple & sweet
  • und so weiter.

Der Grundsatz besagt, dass man das Design so einfach wie möglich halten soll. Die Vereinfachung des Designs soll verschiedene Vorteile bieten. Das Prinzip lässt sich auf unterschiedlichste Bereiche anwenden. In einer Softwareentwicklung könnte man mögliche Vorteile wie folgt auflisten:

  • bessere Übersichtlichkeit
  • einfacher zu bedienen
  • einfacher zu warten
  • verwendet weniger Ressourcen.

Einfacher ist aus diesen Gründen besser. Das KISS-Prinzip hat sich in vielen Situationen als nützliche Idee erwiesen. Die Herausforderung liegt jedoch in der Vereinfachung.

Einfacher oder vollständiger?

Wie lässt sich das KISS-Prinzip anwenden? Gibt es für die Vereinfachung auch Grenzen?

Oft kann man eine Funktion auf einen einzigen Script-Schritt reduzieren. Wer etwas erreichen will und das durch einen einzigen Script-Schritt erreichen kann – anstelle durch viele komplexe Zwischenschritte – hat etwas gut verstanden. Das wäre analog dem KISS-Prinzip. Einfacher ist besser.

FileMaker ist stark in diesen Dingen, weil es komplexe Sachverhalte oft auf einen konfigurierbaren Script-Schritt reduziert. Allerdings ist diese Vereinfachung zwar zielführend, aber nicht immer maximal deutlich. Das möchte ich anhand eines Beispiels aufzeigen.

Stufe 1: Der Minimalist

Wer etwas mit nur einem Script-Schritt lösen kann, zeigt sich als Meister. Simple is beautiful. Das hat jedoch Grenzen. Bei vielen Script-Schritten lassen sich Berechnungen einfügen. In der Script-Übersicht sind diese Berechnungen meist nicht oder nur teilweise sichtbar.

Erst ein weiterer Klick und ein weiteres Fenster zeigen, welche Berechnung im Hintergrund liegt. So funktioniert das in FileMaker. Eventuell sieht man gar nicht, dass eine Berechnung hinterlegt ist. Dann ist zwar die Funktion sehr einfach, aber die Darstellung in FileMaker verhüllt auch bestimmte Abläufe. Das hat Vor- und Nachteile, ist jedoch für die Übersichtlichkeit nicht optimal.

Stufe 2: Der Erfahrene

Eine mögliche Lösung wäre es, die Berechnung durch einen Variablen zu ersetzen und die Variable selbst der Funktion vorauszusetzen. Man kann so vorgehen, dass Berechnungen immer in Variablen stattfinden. Der Name einer Variablen kann einen Hinweis auf die Berechnung liefern. Es wird übersichtlicher. Damit gäbe es zwei Scriptschritte:

  • Setze Variable (mit Berechnung)
  • Benutze Variable (in der eigentlichen Funktion).

Dieses Vorgehen teilt in zwei Schritte auf, was auch in einem Schritt ginge. Der Vorteil liegt hier nicht in der «möglichst kürzesten Umsetzung», sondern eher in der Übersichtlichkeit. Wer das Script aufschlägt, sieht in der Übersicht Variable und Anwendung in zwei Schritten nacheinander. Ein Schritt mehr kann verdeutlichen, dass hier etwas berechnet wird und damit kann die Übersichtlichkeit gedient sein.

Stufe 3: Der Weise

Die Überlegungen können noch weitergehen. Es kann hilfreich sein, zusätzlich ein kurzer Kommentar zu erfassen. Viele Entwickler haben festgestellt, dass eine gut-kommentierte Softwarelösung später einfacher zu warten ist. Ein Kommentar wird demnach im Hinblick auf die spätere, einfachere Wartung angelegt. Wir haben nun drei Zeilen:

  • Kommentar
  • Setze Variable
  • Benutze Variable (in Funktion)

Evaluation der Entwicklung

Was ist jetzt besser, die kürzere direkte Umsetzung oder die besser lesbare Variante mit einer Erklärung für später? Mit diesem Beispiel möchte ich aufzeigen, dass das KISS-Prinzip gut ist, jedoch können Gründe dafür sprechen, eine Aufgabe etwas ausführlicher umzusetzen.

Wo liegt hier der Unterschied? Der Unterschied liegt in der Bewältigung der Komplexität, aber auf zwei verschiedene Ebenen.

  1. Die Funktionalität
    Wer ein komplexer Vorgang auf einen einzigen korrekten Script-Schritt reduzieren kann, hat die Möglichkeiten von FileMaker (oder einer anderen Entwicklungsplattform) gut erfasst. Das ist der Kern, um den es geht. Die Bewältigung der Komplexität konnte durch eine starke Vereinfachung erreicht werden.
  2. Die Darstellung
    Die beiden weiteren Zeilen, die nun hinzugefügt werden (Kommentar und Variable) befassen sich nicht mehr mit der Funktionalität, sondern verbessern lediglich die Darstellung. In der Übersicht ist dadurch auf Anhieb klar, was gemeint wird (Kommentar) und wo man eine Berechnung prüfen sollte (Variable).

Es gibt so viele Meinungen zum Thema, wie es FileMaker-Entwickler gibt. Mir geht es hier nicht darum, zu entscheiden, was wichtig ist, oder wie man etwas machen «sollte». Dieser Beitrag ist bloss eine Reflexion. Heute sehe ich deshalb die drei genannte Schritten als Entwicklungsansätze:

  1. Funktion (Minimalismus)
  2. Variable (Erfahrung)
  3. Kommentar (Weisheit)

Besonders wichtig: Der Minimalist hat gute Gründe, genau so vorzugehen, und keine Zeile zu viel zu schreiben. Wer Berechnungen sichtbar macht, hat aus seiner Erfahrung gelernt, dass dadurch die Scripts besser lesbar sind. Wer ausserdem noch Kommentare hinzufügt, hat verstanden, dass er selbst nach einem Jahr vermutlich nicht mehr weiss, warum das Script so und nicht anders geschrieben wurde. Von jedem Ansatz lässt sich etwas lernen.

Vereinfachung der FileMaker Entwicklung

Das KISS-Prinzip ist nur eines von vielen Möglichkeiten, eine Vereinfachung anzustreben. Selbstredend gibt es weitere Möglichkeiten, die FileMaker Entwicklung zu vereinfachen. Dabei stelle ich fest, dass es verschiedene Ansätze gibt. Welche Variante man bevorzugt, hängt möglicherweise vom eigenen Temperament ab oder von besonderen Anforderungen des gerade aktuellen Projektes. Welche sind die Varianten?

  1. Mehr Regeln
    Einige streben Systeme an, worin alle Details der Entwicklung definiert sind. Es gibt nicht bloss «best practices», sondern man stellt ein Regelwerk auf, wonach sich der Entwickler zu richten hat. Für alles gibt es eine Definition: Wie man Dinge benennt (etwa Feldnamen, Tabellen, Layouts), wie man sie referenziert und welche Konzepte für die gesamte Applikation gelten.
    Nachteil eines Regelwerkes: Es kann ein Eigenleben anfangen und viele Ressourcen und Zeit binden.
    Bedenkenswert: Ein Regelwerk soll dem Entwickler helfen und der Entwickler soll nicht dem Regelwerk dienen.
  2. Weniger Regeln
    Andere, vermutlich die meisten Entwickler, richten sich nach «best practices» und einem reduzierten Regelwerk. Ganz ohne eigene Vorgaben wird man nicht auskommen, aber der Fokus liegt nicht auf dem Regelwerk, sondern auf einer Struktur. Die Struktur soll dem Entwickler helfen, sich jetzt und auch in Zukunft zurechtzufinden. Nicht «wie» man etwas macht, sondern «wo» man etwas findet, steht zentral.
    Nachteil eines Struktur-Prinzips ist gerade die Freiheit des Entwicklers.
    Bedenkenswert: Entwickler tun gut daran, sich bewusst eine Struktur zurechtzulegen und diese konsequent zu nutzen.

Die Vereinfachung der Entwicklung hat immer etwas von einem Abenteuer. Welche Dinge sich bewähren, wird man erst im Nachhinein feststellen. Man braucht den Mut, nicht nur aus der eigenen Erfahrung, sondern auch von anderen Kollegen dazuzulernen, Fehler zu machen, und bewährte Ansätze sukzessive in die eigene Arbeit einfliessen zu lassen.

Wer lernend unterwegs ist, wird feststellen, dass man sich ändert, mit der Zeit bessere Entscheidungen trifft und rückblickend vieles etwas chaotisch gemacht hat. Es braucht Mut zur Lücke, wenn man das feststellt. Selten nämlich lassen sich die alten Fehler neu programmieren. Manchmal jedoch ist es unerlässlich. Dieser Prozess ist spannend und es gibt Methoden, den Schmerz in Grenzen zu halten. Vereinfachung ist eines dieser Methoden.

KISS: Keep it simple & smart.

Anregungen für die FileMaker Entwicklung

Das KISS-Prinzip und andere Ansätze lassen sich auf viele Bereiche der Entwicklung anwenden. Hier entstehen nach und nach weitere Beiträge zur Arbeit mit FileMaker. Sie sind als Anregungen für die eigene FileMaker Entwicklung gedacht.


Grössere Projekte als Add-on speichern

Erfahrungsbericht

Grössere Projekte als Add-on speichern

Getestet mit FM Starter 2


28. Mai 2021In Add-ons, FM Starter, TippsBy Karsten Risseeuw8 Minutes

FileMaker Add-ons werden oft als kleine Lösungen angepriesen. Wie ist es jedoch, wenn man grössere Projekte, mit vielen Tabellen, Scripts, Layouts, usw. als Add-on exportiert. Geht das?

Die Herausforderung

Alle mir heute bekannte Add-ons für FileMaker sind «kleine» Projekte. Es sind Funktionen, einfache Lösungen mit relativ wenig Tabellen, Layouts und Scripts. Kann man grössere Add-ons generieren und warum sollte man das wollen?

Die Frage, ob man grössere Add-ons generieren kann, habe ich getestet. Dazu gleich mehr. Aber warum sollte man das wollen? Ist es nicht genug, dass man kleine, spezifische Projekte lancieren kann? Nun, Add-ons sind praktisch und manche Aufgaben sind etwas komplexer, benötigen also komplexe oder grössere Add-ons.

Man kann beispielsweise eine einfache aber komplette Adressverwaltung als Add-on erstellen. Das könnte ein Basis-Modul zur weiteren Entwicklung sein, mit allen wichtigen Tabellen bereits verlinkt und einige Funktionen eingebaut. Ebenso liesse sich ein Rechnungsmodul als Add-on entwickeln, mit den Basistabellen für Belege, Rechnungspositionen, Drucklayouts, usw. Es geht um die Frage, wie gross oder komplex die Bausteine sein dürfen.

Gelingt es, grössere Bausteine zu erstellen, dann gelingen auch andere Projekte schneller.

FM Starter als Add-on

FM Starter ist die Startdatei, die wir als Produkt verkaufen. Mit ihr lässt sich jedes neue FileMaker-Projekt besonders schnell einrichten und wichtige Funktionen sind bereits integriert. Es ist eine grosse Starthilfe für alle «neuen» Projekte. So vermarkten wir das auch.

Regelmässig habe ich jedoch Entwickler am Telefon, die bereits ein Projekt am Laufen haben, und gerne die Funktionalität von FM Starter integrieren würden. «Kann man FM Starter auch in ein bestehendes Projekt integrieren?» ist eine Frage, die ich regelmässig höre. Meine Antwort darauf ist stets: Ja, das geht, aber…

FM Starter ist fast komplett modular aufgebaut. Dadurch kann man FM Starter Modul für Modul in eine andere Datei übernehmen. Es geht, auch wenn es aufwändig ist. Relationen gibt es keine (ausser 1 Relation für die Design-Seite, wodurch Portale dargestellt werden können). Die Voraussetzungen sind also gut. Die Datei hat trotzdem recht viele Tabellen, unzählige Scripts, Einstellungen und viele Dinge mehr. Erschwerend ist, dass viele Module sich gegenseitig nutzen. Beispielsweise nutzt das Modul «Navigation» die Module «Benutzerverwaltung» und «Mehrsprachigkeit».

Möchte man die Originaldatei von FM Starter in ein anderes Projekt integrieren, dann ist das sehr aufwändig. Kann man die gesamte Startdatei als Add-on speichern, dann ebnet das den Weg zur Integration in andere Projekte. Es wäre viel einfacher, die Datei mit dem FM Starter Add-on auszustatten.

Einschränkungen bei Add-ons

FileMaker Add-ons übernehmen Tabellen, Layouts, Objekte, Scripts und Custom Functions. Nicht jedoch werden Sicherheitseinstellungen und Konten übernommen. Diese beiden Dinge sind jedoch integrierter Bestandteil von FM Starter. Was passiert, wenn man diese Einstellungen verliert?

Der Test

Bevor man aus einer geschützten Datei wie FM Starter ein Add-on machen kann, muss man die Datei mit vollen Zugriffsrechten öffnen. Danach habe ich die Datei mithilfe von Add-On Lab FREE ausgewählt und als Add-on Paket gespeichert. Was geschah?

Erstaunlicherweise hat es geklappt. Es braucht aber Zeit. Beim Sichern der Datei als Add-on war FileMaker minutenlang eingefroren. Ich sah jedoch auf der Festplatte, dass Daten geschrieben wurden. Als das Add-on gespeichert war, habe ich eine neue, leere Datei geöffnet und dort das Add-on geladen.

Auch das Laden des Add-ons braucht seine Zeit. Danach stand FM Starter jedoch in einer neuen Datei zur Verfügung. Ich war erstaunt, dass es beim ersten Anlauf funktioniert hat. Nun aber musste ich das Resultat testen.

Bei diesem Test hatte ich keine «Drag-and-drop» Dateien erstellt. Es gab also nichts, was ich auf die Seite ziehen könnte. Das spielt jedoch keine Rolle, da beim Import des Add-ons bereits die ganze Funktionalität importiert ist. Das sieht man beispielsweise an die Liste mit Layouts.

Es wurden insgesamt 25 Tabellen mit ihren Datensätzen angelegt.

Die Konten und Sicherheitseinstellungen wurden – wie erwartet – nicht übernommen.

Bei den Scripts dagegen wurde die ganze Liste sauber übernommen.

Was funktioniert nicht?

In einem ersten Vergleich der Originaldatei mit dem Add-on sind ein paar Dinge aufgefallen:

  • Dateieinstellungen werden nicht übernommen.
    • Das StartUp-Script ([OnFirstWindowOpen]) wurde nicht zugeordnet.
    • Das CloseDown-Script ([OnLastWindowClose]) wurde ebenfalls nicht zugeordnet.
    • Diese und weitere Einstellungen lassen sich schnell beheben, sofern in einer bestehenden Lösung nicht bereits ähnliche Triggers konfiguriert waren. Ansonsten muss man diese Aufgabe lösen.
  • Die Navigation hat nicht auf Anhieb funktioniert
    • Dies hat zuerst mit dem StartUp-Script zu tun, dann aber auch mit fehlenden Konten, die beim Start ausgeführt werden
    • Diese und weitere Einstellungen können jedoch leicht angepasst werden.
  • Einige Layouts waren nicht sauber aufgebaut. Es gab einen Fall, wo der Button-Bar nicht sauber dargestellt war. Der Stil musste neu zugeordnet werden und das Objekt musste korrekt platziert werden.
  • Textobjekte erhalten pauschal die Textformat-Einstellungen der ersten Zeile. Eine differenzierte Hervorhebung «im» Text geht verloren und muss neu zugeordnet werden.

Alles in allem hat erstaunlich viel auf Anhieb funktioniert. Einige Anpassungen, die gemacht werden mussten, waren zu erwarten.

Können komplexere Add-ons erstellt werden?

Im Moment kommt man nicht ums Experimentieren herum. Die «FM Starter 2»-Datei wurde ohne Anpassungen zu einem Add-on umgewandelt. Dass dies weitgehend gelang, werte ich sehr positiv. Möchte man jedoch ein zuverlässiges Add-on erstellen, wäre es sinnvoll, die ursprüngliche Datei für diese Anwendung zu optimieren. Ausserdem benötigt es eine Dokumentation dazu, welche Anpassungen vom Entwickler noch gemacht werden müssen. Diese Anpassungen sind nicht nötig, wenn man die Startdatei direkt als Ausgangslage benötigt. Fehlen bei einem Add-on jedoch die FileMaker Konten und Zugriffsberechtigungen, kann das Add-on nicht so funktionieren wie in der Originaldatei.

Spezielle Aufmerksamkeit gilt demnach:

  • Dateieinstellungen
  • Konten und Zugriffsrechte.

Dieser kleine Erfahrungsbericht will aufzeigen, dass die Arbeit mit Add-ons keine Hexerei ist. Die guten Anwendungen entstehen erst und ich bin gespannt auf weitere Entwicklungen.

FM Starter 2

FileMaker Scripts für verschiedene Aufgaben gleichzeitig nutzen

FileMaker Scripts für verschiedene Aufgaben gleichzeitig nutzen

So erreichst Du mehr mit Deinen FileMaker Scripts


7. April 2021In TippsBy Karsten Risseeuw7 Minutes

FileMaker Scripts dienen dazu, Abläufe zu standardisieren. Es ist die «Programmiersprache» von FileMaker, wenn man so will. Meist werden Aktionen durch Klick auf ein Button ausgelöst. Ein Script im Hintergrund erfüllt dann die Aufgabe. Arbeitsabläufe lassen sich so besonders einfach erstellen. Bei einer wachsenden Applikation wachsen auch die Anzahl Scripts, bis es unter Umständen Hunderte Scripts gibt. Schnell wird so etwas unübersichtlich. Dabei bestehen viele Scripts oft nur aus ein paar Zeilen. Kann man dies vereinfachen?

Ja, man kann Scripts vereinfachen. Folgende Vorgehensweisen haben sich bei mir bewährt:

  1. Scripts möglichst pro Layout erstellen
  2. Scripts möglichst pro Tabelle gruppieren
  3. Verschiedene kleinere Scripts in einem Script zusammenfassen.

Die Basisidee soll immer sein, kleinere Einheiten zu erstellen, die man gut prüfen kann, um diese dann für grössere Aufgaben zusammenzufassen.

Alle Scripts mit Wenn-Abfragen steuern

Als Faustregel wird bei mir jedes Script mit einem Scriptparameter aufgerufen. Ruft man ein Script ohne Scriptparameter auf, dann geschieht gar nichts. Die Funktionalität steht immer in einer Wenn-Abfrage. Das erhöht nicht nur die Sicherheit, sondern erlaubt auch die Verwendung des einen Scripts für mehrere Aufgaben.

Viele Scripts erledigen nur kleinere Aufgaben. Beispielsweise habe ich oft eine Seite mit Einstellungen, die ich anpassen kann. Diese Einstellungen kann ich sichern und wieder einlesen. Problemlos lassen sich beide Aufgaben (sichern/einlesen) in einem einzigen Script unterbringen. Beispielsweise so:

In diesem Screenshot ist eine vereinfachte Darstellung. Ganz oben steht der Name des Scripts. Dort kann man noch mehr Informationen ergänzen, wenn man will. Darunter gibt es eine Liste mit allen Script-Parametern, womit das Script aufgerufen werden kann. Das dient der Übersichtlichkeit und ist gleichzeitig so etwas wie ein Index zum Script. Die Script-Parameter zeigen die Abschnitte im Script. Erst danach folgt die eigentliche Funktionalität.

  1. Script-Name
  2. Liste mit Script Parametern, womit das Script aufgerufen werden kann
  3. Die eigentliche Funktionalität in Wenn-Abfragen.

Jeder Abschnitt erscheint dann mit einer Wenn-Abfrage. Möchte ich beispielsweise in einem Script das Lesen und Schreiben von Voreinstellungen erledigen, könnte das Script so aussehen:

Wenn [ Hole ( ScriptParameter ) = “schreiben” ]
*** HIER DIE LOGIK ***
Ende

Wenn [ Hole ( ScriptParameter ) = “lesen” ]
*** HIER DIE LOGIK ***
Ende

Damit erhalte ich ein Script, womit ich verschiedene Aufgaben lösen kann. Das reduziert die Anzahl Scripts. Ich habe Scripts, die oft bis zu einem Dutzend kleinere Aufgaben erledigen. Das ist keine Vorgabe, sondern eine Möglichkeit, sich die Arbeit zu erleichtern.

Teilaufgaben nutzen

Mit dieser Vorgehensweise lassen sich Teilaufgaben sauber trennen und trotzdem zusammenhalten. Statt ein Script mit vielen Unterscripts zu nutzen, können die Aufgaben vielleicht in einem Script zusammengefasst werden. Jede Wenn-Abfrage kann eine Teilaufgabe sein. Das hält die Scripts übersichtlich und man kann Teilaufgaben nacheinander oder einzeln abrufen.

Teilaufgaben können auf zwei Arten aktiviert werden:

  1. Man ruft aus dem Script dasselbe Script mit einem anderen Parameter auf
  2. Man ergänzt eine Wenn-Abfrage mit einem weiteren Parameter, der dann weiter unten im Script aufgegriffen wird.

Zur zweiten Variante hier eine Erklärung: Selbstverständlich sollen Script-Parameter beim ersten Aufruf des Scripts gesetzt werden. Das hält jedoch nicht davon ab, im Verlauf des Scripts immer den nächsten Schritt anzugeben – beispielsweise mit einer Variablen.

Wenn [ Hole ( ScriptParameter ) = “schreiben” ]
*** HIER DIE LOGIK ***
Variable setzen [ $NextStep ; Wert: “output” ]
Ende

Hier wird am Ende einer Wenn-Abfrage eine Variable gesetzt mit dem Stichwort “output”. Diese Variable soll auf den nächsten Schritt mit dem Namen “output” hinweisen. Insofern dieser Abschnitt in einer weiteren Wenn-Abfrage enthalten ist, sollte nach dem Abschluss des ersten Abschnitts, nun der zweite Abschnitt aktiviert werden. Das kann man beispielsweise so machen:

Wenn [ Hole ( ScriptParameter ) = “output”  oder  $NextStep = “output” ]
*** HIER DIE LOGIK ***
Ende

Die Ergänzung bei der Wenn-Abfrage ist nun so formuliert, dass man diesen Teil entweder mit einem ScriptParameter oder mit einer lokalen Variable aus dem Script ansteuern lässt. So lassen sich in einem Durchlauf mehrere Abschnitte «abarbeiten», ohne, dass man das Script mehrfach abrufen muss.

Machen diese Angaben einen Sinn? Das ist vielleicht nicht nur eine Frage des Programmierstils, sondern hängt ebenso mit der Art von Projekten zusammen, wofür man arbeitet. Bei mir steht immer die Frage voran: «Wie halte ich alles so einfach wie möglich?».

Warum sollte man dies anwenden?

Nachdem ich den Text hier oben auf Social Media gepostet hatte, wurde die Frage gestellt «Warum sollte man dies anwenden?». Ich wurde mir bewusst, dass ich noch nichts über die Gründe gesagt hatte, wieso ich zu dieser Strukturierung kam. Dazu nun hier ein paar Worte:

Zuerst einmal ist es einfach eine (von vielen) Methoden, Scripts zu schreiben. Es sind keine Vorgaben. Bei mir waren es verschiedene Erfahrungen, die zu dieser Methode geführt haben:

Herausforderungen

  1. In grösseren Datenbanken hatte ich Hunderte Scripts. Viele davon waren nur ein paar Zeilen gross.
  2. Öfters hatte ich dieselbe Funktion an mehreren Orten integriert oder ich hatte mehrere Scripts dafür im Einsatz.

«Je grösser» bedeutete nun auch «desto unübersichtlicher». Deswegen hatte ich folgende Anliegen:

Optimierungswünsche

  1. Reduziere die Anzahl Scripts
  2. Vermeide Redundanzen bei den Funktionen
  3. Erleichtere die Gesamtstruktur aller Scripts
  4. Optimiere die Möglichkeiten jedes einzelnen Scripts.

Die Ideen einer modularen Entwicklung von FileMaker Funktionen zeigten mir auf, wie das möglich ist. Insbesondere folgende Ansätze erwiesen sich als hilfreich:

Umsetzung

  1. Gruppiere Scripts möglichst nach Tabelle / Layout
  2. Reduziere Scripts idealerweise auf die «eigenen» Tabellen / Layouts
  3. Fasse mehrere Funktionen pro Tabelle / Layout in einem einzigen Script zusammen
  4. Jedes Script hat so mehrere «Teile», die durch einen ScriptParameter angesteuert werden können.

Soll dies jetzt eine rigide Regel sein? Nein. Es hat bei mir jedoch alle Scripts vereinfacht und die Anzahl Scripts drastisch reduziert. Als Methode hat sich das bei mir bewährt.


Wie sich iPad und iPhone in FileMaker erkennen lassen

Wie sich iPad und iPhone in FileMaker erkennen lassen


10. Februar 2021In FM Starter, TippsBy Karsten Risseeuw1 Minutes

Erstellt man eine Datei für iOS-Geräte, muss man dort vermutlich unterscheiden können zwischen iPhone und iPad. Beim Starten der Datei muss man eine Abfrage erstellen, aufgrund dessen ein Layout für iPhone oder iPad angesteuert wird. Dies soll möglich sein mit der Statusabfrage:

Hole ( ProgrammVersion )

Läuft die Datei auf dem iPhone, ist das Resultat «Go», während es auf dem iPad das Resultat «Go_iPad» zurückmeldet. Eine komplette Abfrage lässt sich laut der FileMaker Hilfe wie folgt erstellen:

MusterAnzahl ( Hole ( ProgrammVersion ) ; “Go” ) für iPhone, und
MusterAnzahl ( Hole ( ProgrammVersion ) ; “Go_iPad” ) für iPad

Baut man diese Abfrage ein, zeigt sich, dass dies nicht gut funktioniert. Beide Anfragen erkennen nur ein iPhone. Das ändert sich auch nicht, wenn man statt “Go_iPad” nur noch “iPad” für die Mustererkennung eingibt.

Eine einfache Lösung besteht darin, lediglich für iOS zu suchen und dann pro Abfrage explizit das Gerät zu eruieren:

Hole ( Gerät ) = 4, für iPhone
Hole ( Gerät ) = 3, für iPad

Dies funktioniert tadellos.

Anpassung für FM Starter

Im nächsten Update von FM Starter wird dies für die Navigation angepasst. Wer das heute bereits anpassen möchte, muss dies hier anpassen:

Script: GN GetSystemLayout, line 25.

Let (
a = Get ( ApplicationVersion ) ;

Case (
PatternCount ( a ; “Pro” ) ; 1 ;
Get ( Device ) = 4 ; 2 ;
Get ( Device ) = 3 ; 3 ;
PatternCount ( a ; “Web” ) ; 4 ;
1 )
)


Ein eigenes Filemaker Pro Entwicklunssystem bauen

Baue Dein eigenes Filemaker Pro Entwicklungssystem

Wer als Filemaker Entwickler anfängt, wird vermutlich dieselben Fehler machen, die andere auch machen. Daran ist nichts falsch, und es hilft sogar dabei zu verstehen, auf was es wirklich ankommt. Man nennt dies «Erfahrung» und es ist ein zuverlässiger und bereichernder Weg, zu einem besseren Verständnis zu gelangen.

Es gibt verschiedene Gründe, weshalb Entwickler früher oder später nach einem System Ausschau halten. Dabei geht es nicht um bestimmte Konventionen, aber mehr um eine bestimmte Arbeitsweise. Man will wiederkehrende Aufgaben besser lösen, oder vielleicht einfach eine Startdatei zum Anfangen haben. Häufig gibt es mehrere Wege, die zu einer guten Lösung führen. Einige Wege sind aber effizienter als andere. Verbesserungen anzustreben heisst in der Regel, dass man bessere Ansätze verwendet und effizientere Methoden für bestimmte Herausforderungen findet, oder dass man allgemein den Arbeitsfluss verbessert.

FM Starter kann eine mögliche Variante sein, um schneller zum Ziel zu gelangen. Auch wenn die Lösung bei weitem nicht «perfekt» ist, löst sie doch eine Reihe von Herausforderungen womit sowohl ich selbst als auch andere jahrelang gerungen haben. Heute denke ich, dass FM Starter noch drastisch vereinfacht werden kann. Die Vereinfachung von Funktionen, von Abläufen, von Betrachtungsweisen ist vielleicht der grösste Wert, den man als Entwickler mitbringen kann. Die Bewältigung komplexer Aufgaben ist nämliche eine Sache, die Fähigkeit sie zu vereinfachen jedoch eine andere.

Ich habe grosse Bewunderung vor Entwicklern, die wirklich komplexe Aufgaben mit Bravour meistern. Komplexität ist manchmal vorgegeben, aber wenn etwas einfacher geht – weshalb dann nicht vereinfachen? Je besser man etwas versteht, desto leichter fällt es, den Arbeitsfluss oder die Programmierung zu vereinfachen. So kann eine Lösung oder System nicht nur erweitert, sondern auch tatsächlich verbessert werden. Arbeitsschritte können reduziert, vereinfacht und verkürzt werden. Zusammenhängende Abläufe werden vielleicht besser aus kleineren Teilen aufgebaut, oder – umgekehrt – vielleicht besser in einem einzigen Schritt erledigt. Wer es versteht komplexe Abläufe in einfacheren Schritten aufzuschlüsseln, hilft damit sich selbst und anderen, die Arbeit auch Jahre später nachzuvollziehen.

Wer ein System vor Augen hat, profitiert auf lange Sicht von einer möglichst einfachen Lösung. Konventionen und komplexe Regelwerke können nur wenige Menschen verarbeiten. Die Abgrenzung von einzelnen Abläufen schafft auf Dauer eine grosse Flexibilität – auch zur Verbesserung. «Reduce to the max» wäre hier die wegweisende Reduktion auf wenige gute Prinzipien, Arbeitsabläufe und Funktionen.

Beginnt man ein System aufzubauen, gilt es die eigene Arbeitsweise zu berücksichtigen. Haben Sie bewährte Vorgehensweisen? Oder suchen Sie nach neuen Möglichkeiten? Die aktuelle Lösungen werden mit Sicherheit künftig von noch besseren Lösungen abgelöst. Es spielt demnach keine wirkliche Rolle, womit man anfängt, solange man selbst zügig damit arbeiten kann. Bestimmte Ansätze werden sich bewähren, während andere mit der Zeit wieder verschwinden werden. Einige Anwender von FM Starter benutzen die Lösung wie sie ist, und bauen darauf auf. Andere wiederum benutzen FM Starter lediglich als Anregung, und implementieren diese oder jene Ideen in bereits bestehenden Lösungen. Es gibt hier kein Falsch oder Richtig. Pflanze einfach einzelne Bäume, und vielleicht hat man nach einigen Jahren einen eigenen Obstgarten.

Ein eigenes System

Hier einige Fragen zur Evaluation einer Starterlösung:

  • Was will ich vereinfachen?
  • Kann ich das selbst in nützlicher Frist?
  • Gibt es eine brauchbare Alternative, die mir den Weg verkürzt?
  • Was wäre am dringendsten zu realisieren?
  • Welche eigene Konzepte sind überholt und bedürfen einer Neuorientierung?
  • Wenn man die Prioritäten nach dem Grundsatz «Wichtiges vor Dringendes» einrichtet, was müsste man tun?