Ich hatte mich schon gewundert, dass du das in deinem Video nicht erwähnt hast. ;)

Ist natürlich nicht schön und reduziert den Nutzen der Funktion erheblich. Denn die Möglichkeit des Vergrößerns der Zeilenhöhe macht ja vor allem Sinn bei einzelnen Tabellen, die längere/mehrzeilige Inhalte darstellen will. Wenn dann die Zeilen auch bei allen anderen Tabellen plötzlich doppelt so hoch sind, lässt sich die Funktion nur temporär nutzen. Und man muss die Höhe immer wieder ändern.

Davon abgesehen: Schönes Video!

"will" = "soll"

"Bug" im Sinne von "Ups, haben wir gar nicht gemerkt!" kann ich mir nur schwer vorstellen. Die Einstellung der Zeilenhöhe wirkt sich ja auf alle Teams und Datenbanken aus, muss also irgendwo nutzerbezogen gespeichert werden. Sowas passiert ja kaum aus Versehen. Es wäre m. E. eher ein Feature-Wunsch, die Funktion dahingehend zu erweitern, dass die Zeilenhöhe für jede Tabelle gespeichert wird. Denn das es die Möglichkeit der Anpassung gibt, ist ja erst mal gut. 

Sorry, wenn die Anpassung der Zeilenhöhe nur global für alle Tabellen greift, ist das IMHO kein Feature sondern klar ein BUG. Ob das Verhalten seitens Ninox so gewünscht ist, ändert nichts an der Einordnung als Bug. Für die Einordnung als "nutzloses Feature" müsste man allenfalls einen neuen Begriff kreieren ("Neature" vielleicht?) ;-)

lg, Torsten

Na ja, im Grunde ist es natürlich Wortklauberei, aber für mich ist ein Bug per Definition ein Programmfehler. Hier geht es aber um ein neues Feature, dessen potenzieller Nutzen durch die Art der Umsetzung eingeschränkt ist. Bisher ließ sich die Zeilenhöhe gar nicht ändern, und kaum jemanden hat's gestört. Jetzt kann man es bei Bedarf tun, muss es aber nicht. Für mich ist das ein Fortschritt, wenn auch in der vorliegenden Form nur ein kleiner.

Ist ähnlich wie bei den "Deep Links", die enttäuscht haben, weil man sie (noch) nicht (ohne weiteres) auslesen kann. Aber ein Bug?

Okay, ninox hätte bei der Kommunikation auf die Besonderheit hinweisen können, damit die Nutzer beim ersten Mal nicht irritiert sind. Aber wo ist da jetzt das konkrete Problem, das notwendigerweise dringend gelöst werden müsste, um die Funktionalität der Software sicherzustellen? Man kann die Zeilenhöhe ja auch so lassen, wie sie ist.

Da gibt es wirklich andere Dinge, die mich wesentlich mehr stören und die ich als dringlicher empfinde. Details erspare ich uns aber jetzt. ;)

Wollt ihr mal einen echten Bug in der neuen Version sehen, der mir eine komplette Produktivdatenbank zerballert? Hier überlagern sich 2 Tabellen, wobei die hintere den Fehler auslöst und die Darstellung das einfroren auch bei Tabellenwechsel übernommen wird. 

Zudem habe ich noch eine handvoll anderer Bugs entdeckt und bin seit 2 Tagen nur noch dabei, die Datenbanknutzer zu beruhigen, weil nix mehr geht. Selbst Formelfelder werden teils falsch oder gar nicht berechnet.

openTable-Befehle im Trigger "Ausführen, wenn Datenbank gestartet wird" reagieren nicht mehr auf versteckte Tabellen, nur noch auf öffentliche. 

Die schwarze Admin-Leiste spinnt, wenn man bei einem popup-Record in den Admin-Modus wechselt.

achso, alles in der Cloud. Sorry

Hallo Icarus Manifest,

"Zudem habe ich noch eine handvoll anderer Bugs entdeckt und bin seit 2 Tagen nur noch dabei, die Datenbanknutzer zu beruhigen, weil nix mehr geht. Selbst Formelfelder werden teils falsch oder gar nicht berechnet."

Ich kann Dich sehr gut verstehen - ich sitze im gleichen Boot und versuche ebenso, meine Kunden zu beruhigen und die undokumentierten Änderungen, Bugs und Fehlfunktionen in den Datenbanken zu finden und als erste Schnell-Lösung andere Programierungen umzsetzen, damit die Funktionalität der Datenbanken bis zum hoffentlich bereingten Update 3.xx erhalten bleibt.

Da auch grundsätzlich Basisfunktionen nach wie vor fehlen bzw. immer noch fehlerhaft sind (Drucklayout mangelhaft, Tabellenansichten werden nach  Feldänderungen  nicht automatisch aktualisiert (z. B. wenn man einen Archiv-Status setzt), ...) kann ich nur hoffen, dass NINOX jetzt schnell und effizient reagiert ...

So, kleines Lageupdate zu meinem Datenbank-Crash:

Nachdem ich gestern bei 7 (!!!) Anrufversuchen in Berlin und per Mail nix erreichen konnte, hat sich heute Frank Böhmer mit der Lösung gemeldet. In der Rückverknüpfung zu einer Untertabelle hatte sich im Spaltenkopf zu einem Textfeld eine leere bedingte Formatierung eingeschlichen. Wahrscheinlich ein "Verklicker" meinerseits, der gereicht hat, damit die gesamte Datenbank jeweils beim 2. Aufruf der Haupttabelle komplett abstürzt. Obwohl man im Übrigen als Admin die bedingte Formatierung jederzeit bearbeiten und löschen kann, sind diese Änderungen nur im aktivierten Admin-Modus so nachhaltig, dass sie den Tabellenwechsel überleben. Den Mehrwert dieser Unterscheidung verstehe wer will. 

Änderungen an Tabellen (bzw. deren Ansichten) waren schon immer nur dauerhaft, wenn im Admin-Modus getätigt. Das macht IMHO auch absolut Sinn...