[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(a)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.
--
Heiko