Bei Größe ändern… Bei Größe ändern… Bei Größe ändern… Bei Größe ändern…

Sie fragen sich, wie Sie eine schöne und dynamische Benutzeroberfläche erstellen können? Wenn die Größe eines Formulars geändert wird, werden die Formularobjekte, deren horizontale oder vertikale Größe so eingestellt ist, dass sie verschoben oder vergrößert werden, in der Regel automatisch in der Größe angepasst. In einigen Fällen (z. B. bei einer feineren Verwaltung der Benutzeroberfläche) entscheiden sich die Entwickler dafür, die Größe und Position der Formularobjekte durch Programmierung zu steuern. Dazu überprüfen sie das Ereignis „on resized“, das innerhalb der Formularmethode ausgelöst wird. Aber was passiert, wenn das Formular ein oder mehrere Unterformulare enthält? Auf vielen Ebenen? Dieser Blogbeitrag gibt Ihnen die Antworten!

Unterformulare und Unter-Unterformulare und…

Die Verwaltung von Unterformularen, wenn die Größe eines „übergeordneten“ Unterformulars geändert wird, mag kompliziert erscheinen, ist es aber nicht! Sie können entweder den Befehl Execute method in subform verwenden oder den zugehörigen Wert des Unterformular-Objekts ändern, gefolgt – innerhalb des Unterformulars – von der Verwaltung des erzeugten on bound variable change Ereignisses.

Ab 4D v18 ist es sogar noch einfacher! Sie können das Ereignis on resize direkt in der Methode des Unterformulars verwalten! Das ist viel bequemer, logischer und einfacher! Dieses Ereignis wird jedes Mal ausgelöst, wenn die Größe des Unterformularobjekts im Hauptformular geändert wird. Dies kann geschehen, wenn:

  • Das Hauptformular wird in der Größe verändert (ebenso wie das Unterformular-Objekt). Dies ist der offensichtlichste Fall.
  • ein Splitter die Höhe oder Breite des Unterformularobjekts ändert. Nicht ganz so offensichtlich, aber dennoch erwähnenswert.
  • Die Größe eines Unterformularobjekts wird durch Programmierung mit dem Befehl OBJECT SET COORDINATES geändert. Dieser Fall ist noch weniger offensichtlich, vergessen Sie ihn nicht 🙂

Schlussfolgerung

Wenn Sie diese Art von Szenarien in Ihrer Anwendung bereits beherrschen, können Sie eine Vereinfachung Ihres Codes in Erwägung ziehen (oder auch nicht! „If it ain’t broke, don’t fix it“). Aber für zukünftige Entwicklungen werden Sie diese Vereinfachung der Ereignisverwaltung zu schätzen wissen!

Roland Lannuzel
- Product Owner & 4D Experte - Nach seinem Studium der Elektronik arbeitete Roland als Entwickler und Berater in der industriellen IT-Branche, wo er Lösungen für Kunden mit einer Vielzahl von Datenbanken und Technologien entwickelte. In den späten 80er Jahren verliebte er sich in 4D und setzte es bei der Entwicklung von Geschäftsanwendungen wie Buchhaltungs-, Abrechnungs- und E-Mail-Systemen ein. 1997 trat er schließlich in das Unternehmen ein und leistete einen wertvollen Beitrag, indem er Spezifikationen, Testtools und Demos entwarf, Schulungen durchführte und auf vielen Konferenzen für die 4D Community sprach. Er gestaltet die Zukunft von 4D aktiv mit, indem er neue Funktionen und Datenbankentwicklungstools definiert.