Mal so als ergänzende Anregung (und wie wir das in unserer BRP Software machen):
Ein generelles Layout für alle Anwender ist immer ein Kompromiss, den der Programmierer vorgibt.
Alle Wünsche aller Anwender zu erfassen ist unmöglich, erst recht dann, wenn auch noch völlig unterschiedliche
Abteilungen oder ganz andere Firmen mit der Software arbeiten.
Wir haben in unserer Applikation einen simplen Designmodus eingebaut, bei dem der Anwender (jedenfalls
dann wenn er in der Software einen Account mit entsprechende Rechten benutzt) die Position aller
Controls selber bestimmen. Wenn er per Rechtsklick Popup Menü den Designmodus aktiviert, dann kann
er jedes Control anklicken und über das OnClick Event werden alle Selektieren Komponenten in eine
TList eingetragen und farblich verändert, so das man erkennt, was markiert ist. Durch erneutes anklicken
wird die Komponente wieder auf normale Farbe gestellt und aus der TList entfernt.
Über simple Tastenkombinationen Ctrl+Cursortasten bzw Alt+Cursortasten kann er nun alle selektierten Komponenten
frei auf dem Form damit pixelweise hin schieben wo er das haben möchte, weil die entsprechenden Events auf dem Form
in entsprechenden popup menu items per short cut hinterlegt sind, aber nur dann aktiv sind, wenn
Designmode aktiv ist.
Beim Beenden des Designmodes (wieder über popup) gehen wir einfach durch die Components im aktuellen form
und schreiben die relevaten Eigenschaften (top/left/height/width) zusammen mit dem Komopnenten Name
in eine TStringlist in so einem Format
edtNachname.left=123
edtNachname.top=10
usw.
Bei uns landet das dann in der Datenbank und kann global für alle User gelten. Optional kann aber auch
ein User sich die vorgegebenen Eigenschaften noch mal überschreiben, so das der mit zB seinem 4K Screen ein
ganz anderes layout hat als seine Kollegen mit zB FHD Screen.
Beim nächsten Laden des Formulars wird dann aus einer Tabellen zu jedem Form je nach o.a. Implementation
die Stringlist aus einem Blob geladen, wieder in eine Stringlist gepackt und im OnShow Event abgearbeitet.
Dabei gehen wir dann einfach wieder durch die automatisch erzeugten Components, holen deren Namen und suchen
in der TStringlist über Values nach der zugehörigen Eigenschaft. Wenn die gesetzt wurde, wird die automatische
Größe/Position verändert und erscheint mit der Anzeige da wo der Endanwender das bestimmt hat.
Das System kann man bis hin zu Schriften, Font Eigenschaften, Farben, Sichtbarkeit usw ergänzen, wenn man will.
Die Tabreihenfolge legen wie fest über die generelle Vertikale Position und wenn top identisch ist geht es innerhalb
der aufsteigenden Left werte weiter. Das ist einfach zu automatisieren.
Die fest einkompilierten Werte aus der
Dfm Datei, die ja nur der Delphi Entwickler bestimmt, kann der mehr oder weniger
talentierte Enduser dann auf Wunsch auf diesem Weg selber anpassen. Alternativ kannst du für deine Software auch unterschiedliche
Layouts auf dem Wege gleich mitliefern.
Bei unserem wichtigsten Kunden für BRP macht ein Mitarbeiter des Kunden immer das komplette Formdesign, ohne jemals
einen Delphi oder Lazarus Compiler benutzt zu haben. Und ganz wichtig: Er überlegt sich auch oft später anhand neuer
Erkenntnisse andere Reihenfolgen innerhalb der Formulare. Da muss er uns nicht mal danach fragen ....
Auf deinen Beispielbildern sieht man ganz gut das bei vielen WAWIs viele Einstellungen möglich sind, die der
Durchschnittsanwender nicht kennt und auch nicht für irgendwas benutzen sollte, wofür es gar nicht gedacht ist.
Das dynamische Ausblenden von solchen Felder erleichtert den Anwendern das leben ganz erheblich und der Programmierer
muss sich nicht 100 Meinungen anhören, in welcher Reihenfolge das denn viel besser wäre. Du gibst nur den Default
vor und überlässt dem Endanwender/Kunden das Customizing. Automatisch angepasste Designs können da auch nur Kompromisse sein.