Das Formular ist in Zeilen und Spalten unterteilt, die sich dynamisch der jeweiligen Fenstergröße anpassen. In Verbindung mit den Gestaltungselementen bieten sich damit sehr viele Möglichkeiten zur schnellen und einfachen Formulargestaltung. Ich persönlich finde das ziemlich genial und hoffe, dass sich daran nichts ändert.

Hallo Marc, du schriebst ja: „Es wäre toll, wenn die Breite der Eingabefelder irgendwo eingegeben werden könnte [...]‟

So kennt man es halt von den Formular-Editoren konventioneller IDEs, bei denen sich die Eigenschaften jedes Steuerelementes individuell einstellen lassen. Für professionelle Entwickler, die regelmäßig damit arbeiten, ist das zweifellos ein Vorteil.

Aber Ninox hat eine ganz andere Zielgruppe und verfolgt deshalb auch einen ganz anderen Ansatz: Einfachheit durch Reduzierung. Also: Je weniger Optionen, desto besser. Davon können dann aber auch professionelle Entwickler profitieren, wenn sie sich auf das Konzept einlassen und Kompromisse eingehen (soweit die Aufgabenstellung dies zulässt).

Aber das soll kein Totschlagargument sein. Gegen eine temporäre Anzeige der Breite während des Skalierens bspw. wäre natürlich nichts zu sagen. Aber welcher Wert sollte da angezeigt werden? Das könnte ja höchstens die Anzahl der Spalten sein. Sowas zu programmieren, wäre aber vermutlich nicht ganz einfach - und der praktische Nutzwert m. E. eher gering. Denn man gewöhnt sich recht schnell an die Vorgehensweise und bekommt ein Gefühl dafür.

Zumal die Breite eines Feldes ja sowieso immer von verschiedenen Faktoren abhängt: Dem zu erwartenden Inhalt, dem zur Verfügung stehenden Platz und anderen Feldern im Hinblick auf eine ausgewogene Gestaltung. Wenn also bspw. das Feld "Ort" in einem Formular 12 Spalten breit ist und im anderen 13, weil es so besser ins Layout passt - wen juckts?

Und wenn es aus irgendwelchen Gründen immer 12 Spalten sein sollen, dann zählt man beim Aufziehen halt selber mit.

Als "Gefrickel" empfinde ich heute, wie ich in den späten 80er-Jahren mit Clipper unter DOS Ein-/Ausgabe-Masken für Bildschirme im 80x25-Textmode erstellt habe: Für jedes Steuerelement genaue Positionswerte berechnen, in den Quellcode tippen, kompilieren, linken, testen - und wieder von vorn. ;)

Im Ernst, ich find's ja gut, dass du dich intensiv mit Ninox beschäftigst und Vorschläge machst. Darüber, dass es noch erhebliches Verbesserungspotenzial gibt, sind wir uns einig. Auch, wenn wir nicht in jedem Punkt einer Meiniung sind. Du solltest aber nicht davon ausgehen, es hier im Forum nur mit DAUs zu tun zu haben. Und "Professionalität" zeigt sich nicht an den verwendeten Werkzeugen, sondern am Ergebnis.

Ich wünsche dir ganz ehrlich viel Erfolg bei der Arbeit mit Ninox und freue mich auf weiteres Engagement in der Community. Wenn du dich mit den vermeintlichen und tatsächlichen Schwächen von Ninox arrangieren kannst, wirst du noch viele tolle Projekte damit umsetzen. Insbesondere solche, für die man den Aufwand einer konventionellen Entwicklung gescheut hätte.

In diesem Sinne - viele Grüße

Axel

Kann mich dem Schlußwort von Planox nur anschliesen, es gibt sicherlich einiges was man verbessern kann. Aber für mich als Laien, empfinde ich die lösungen welche man mit Ninox und seinem sehr Tollen und hilfbereitem Forum erreichen kann super. ( Danke mal an dieser stelle an euch )

Mann darf auch den kostenpunkt außer acht lassen! Wir könnten auch einige bereiche ohne Ninox, mit einem anderen anbieter abdecken. Doch dafür das dieser NUR sein feld abdeckt ... hier bestimmt auch ohne "fehler" kostet die einzellizenz auch gleich mal um die 400 netto pro Arbeitsplatz im Monat!

Ich würde mich freuen Marc, wenn du mit deinem wissen die Teilnehmenden Juser im Forum bei Ihren fragen unterstützen würdest.

Grüße Michi