[Ich habe mal den Thread abgetrennt (Subject und In-Reply-To). Oder habe nur ich das Gefühl, daß mein ursprünglich begonnener ge„hijacked“ wurde?]

Hallo Tobias,

Tobias König tokoe@kde.org (Sa 25 Sep 2010 14:51:03 CEST):

On Wednesday 22 September 2010 23:33:10 Heiko Schlittermann wrote: Hej Heiko,

...

Hm. Irgendwie macht die Library komische Dinge. Ich versuche mal, ein einfaches Beispiel zu bauen und das ganze zu reproduzieren. Aber eigentlich glaube ich immer noch nicht, daß das ins Modell gehört. Das könnte ja auch von anderen Views genutzt werden, und die wollen vielleicht die leere Zeile gar nicht sehen.

Ja, dies sollte nicht in das QSqlTableModel rein, man könnte allerdings ein ProxyModel implementieren, welches eine solche zusätzliche Zeile anbietet und das man zwischen das QSqlTableModel und den QTableView einfügt. Dies ist aber eine ganze Menge zusätzliche Arbeit.

Schön, dann bin ich ja nicht total auf dem falschen Dampfer. Ich war bisher nur am Zweifeln, ob tatsächlich so ein gewaltiger Aufwand für eine scheinbar triviale Angelegenheit notwendig ist. Aber möglicherweise ist meine Sichtweise auf „Trivialität“ ja nicht gültig.

...

Komisch, daß im QSqlTableView diese o. erwähnte neue Zeile keine Zeilennummer erhält, sondern einen „*“. Also scheint jemand zu wissen, daß das kein realer Datensatz ist.

Das '*' bedeutet, dass die Daten noch nicht in der SQL-Tabelle gespeichert wurden. Abhängig von der EditStrategy geschieht dies erst wenn eine neue Zeile ausgewählt wurde oder man manuell mit submit() das Speichern triggert.

Ja. Das leutet mir ein. Aber woher weiß der View, daß dieser Datensatz unecht ist?

Ein interessanter Nebeneffekt, wenn ich nach model->select() noch ein model->insertRow(model->rowCount()) gemacht habe: Sobald an einer der der schon vorhandenen Zeilen etwas editiert wird, gelangt eine Kopie in diese leere Zeile am Ende. Möglicherweise ein Bug, oder in diesem Zusammenhang auch ein Indiz dafür, daß dieses Vorgehen falsch ist.

Das Aufrufen von insertRow könnte funktionieren, du müsstest dies allerdings in einem Slot machen, welcher an die rowsInserted/rowsRemoved Signals des Models gebunden sind, so dass es stets geupdated wird.

Was dann rekursiv wird, weil ja auch meine neu eingefügte Zeile dieses Signal auslösen wird.

...

Und die andere Beobachtung, daß man nicht mehrere leere Zeilen inserten kann. Es zumindest der rowCount scheint sich dann nicht zu ändern.

Ja, der rowCount ändert sich erst, wenn du die Daten wirklich in die Datenbank zurückgespeichert hast.

Ich hätte vermutet, daß Model und Datenbank immer so leidlich syncron sein sollten, gerade nach dem Einfügen von weiteren Zeilen. Wobei ich hier die Ausnahme von leeren Zeilen zur noch verstehen würde.

Ok, also erstmal Proxy-Model.

Oder bessere Vorschläge für ein Nutzerinterface.

Es sollen tabellarische Daten eingegeben werden, und zwar schnell.