TDBNavigator: Insert ist aktiv im Modus "dsEdit"

[Soner]

Wenn die Lazarusentwickler es annehmen wollen, kann ich den Patch reichen, ich kenne ja die Lösung.

[theo]

Wenn die Lazarusentwickler es annehmen wollen, kann ich den Patch reichen, ich kenne ja die Lösung.

Ja klar. Man weiss aber erst ob sie es annehmen wollen, wenn man den Patch "gereicht" hat.
Kostet ja nicht viel, wenn man die Lösung schon hat.
https://gitlab.com/groups/freepascal.or ... s/-/issues

[charlytango]

Sorry for OffTopic..

Schade eigentlich, das sich Lazarus nicht abheben kann gegenüber Delphi.

Tut es ja..... nur nicht immer so wie wir Lazarus-Anwender das gerne hätten.

Aber ja, mit Delphi kann man ja Geld verdienen mit Lazarus nicht.

Diese Aussage gemeinsam mit der vorigen greift meines Erachtens zu kurz.
Und stellt einen doch recht komplexen Sachverhalt sehr vereinfacht dar.
Heutzutage ist es in vielen Firmen immer noch so dass dem OpenSource-Bereich einerseits zuwenig zugetraut wird und andererseits der Besteller von Software seinen eigenen Arsch schützen will/muss.
Deswegen wird oft bei namhaften Herstellern bestellt mit dem Hinweis auf den nötigen Support oder der Größe eun Sicherheite bzw Verlässlichkeit eines Anbieters.
Wie das wirklich aussieht wissen eh alle Beteiligten, aber darum geht es nicht.

Lazarus könnte so viel besser sein.

Ja, könnte es, dann müssten sich aber auch die Strukturen ändern. Es müsste jemand geben der das ganze Projekt nicht nur technisch sondern auch finanziell und im Marketing betreut. Was auch wieder Geld kostet.
Und ob das wirklich klappen kann weiß ich nicht.

[m.fuchs]

Wenn die Lazarusentwickler es annehmen wollen, kann ich den Patch reichen, ich kenne ja die Lösung.

Kannst du den Patch so gestalten, dass die Einstellungen per zusätzlicher Boolean-Eigenschaft an- und abschaltbar sind? Dann wird ja keine Delphi-Kompatibilität gebrochen.

[Joh]

Hmm....
Dazu kommt: Prior und Next stimmen auch nicht.

Das doofe zumindest in der Kombination von Firebird und Lazarus ist:
BoF und EoF werden nicht gesetzt, wenn man auf den ersten/letzten Datensatz geht, sondern erst dann, wenn man versucht, von dort weiterzuscrollen.
Ok, Bei .First (und .Last) funktioniert es, aber bei Prior und Next bekommen die Marker BoF und EoF es erst mit, wenn man schon auf dem ersten/letzten DS war und dann noch einen Schritt weiter hoch/runter gehen will. Also erst beim 2. Klick...

Alternativ zu BoF und EoF kann ich dann mit RecNo und RecordCount arbeiten. Funktioniert sauberer.
Das unschöne am RecordCount ist halt das regelmäßige explizite Fetchall über .Last. Hier lokal am Rechner merke ich das nicht, aber was ist in belasteten Netzwerken, möglichst noch in 100 MBit-Segmenten.
Da bin ich mit solchen Konstrukten wieder genau da, wo ich bei File-basierten Datenbanken (Access, Foxpro) bei der Umstellung auf Windows 7 von SMB1 auf SMB2 war. Plötzlich wurde nicht mehr ein Datensatz (es waren imho zwar Blöcke, aber das ist erstmal irrelevant), sondern bei jedem Refresh die gesamte Datei neu geladen. Anfangs ließ sich das noch anpassen, aber mit jedem Windows-Update wurden weitere Löcher gestopft, so das für mich letztlich nur der Ausweg blieb, Teile der größeren Dateien zu Archivieren.

Nur mal als Anmerkung, das das TDBNavigator-Problem etwas größer ist.

PS:
Ich nutze eh im DBNavigator-Click eine Prozedur SetReadOnly mit Parameter readOnly, die Felder (de-)aktiviert, so das ich dann auch die Buttons auf Enabled/Disabled setze.
Dabei gehe ich bei BoF auf [nbPrior].Enabled := readOnly and (SQLxxx.RecNo <> 1)
und bei EoF auf [nbNext].Enabled := ReadOnly and NOT SQLxxx.EoF;
Das ist zwar auch inkonsistent und inkonsequent, aber ich muß nicht immer drauf achten, das das FetchAll ausgeführt wird.

[Joh]

Ich mach mal die Ingrid:

das Problem dabei ist: ich bin auf Datensatz 1 (oder Reccount),
klicke auf editieren,
ändere etwas,
[nbPrior], [nbNext] sind aber immer noch aktiv... das heißt, wenn ich darauf klicke, mache ich ein implizites Refresh, obwohl ich im Edit-Modus war (bin).
Das darf nicht sein.

[af0815]

RecordCount und Recordnr zu verwenden ist ein absolutes NoGo außer bei Dektopdatenbanken wie Dbase/FoxPro.
Jede Krücke mit .last zeigt, das derjenige sich nie Gedanken über Datenbanksysteme und Datenmengen gemacht hat. Gehört für mich zur "select * " Fraktion.
Da geht nicht um ein paar 100mbit Netzwerke. Da geht es um Verbindungen quer über Kontinente und Software die dann auch noch funktionieren muss.

[wp_xyz]

BoF und EoF werden nicht gesetzt, wenn man auf den ersten/letzten Datensatz geht, sondern erst dann, wenn man versucht, von dort weiterzuscrollen.
Ok, Bei .First (und .Last) funktioniert es, aber bei Prior und Next bekommen die Marker BoF und EoF es erst mit, wenn man schon auf dem ersten/letzten DS war und dann noch einen Schritt weiter hoch/runter gehen will. Also erst beim 2. Klick...

Ich denke, das geht nicht anders, zumindest nicht ohne massiven Umbau von TDataset und Nachfahren. Beim Scrollen durch den Dataset wird nur geprüft, ob ein Record geladen werden konnte oder nicht. Nur wenn nichts geladen wurde, weiß man, dass man sich nun am Anfang oder Ende des Dataset befindet. Andernfalls müsste man beim Scrollen immer drei Records laden, den gewünschten, den vorigen und den nächsten, und dazu ist TDatset nicht "verpflichtet" (obwohl manche einen Block aus mehreren Records laden).

[wp_xyz]

ich bin auf Datensatz 1 (oder Reccount),
klicke auf editieren,
ändere etwas,
[nbPrior], [nbNext] sind aber immer noch aktiv... das heißt, wenn ich darauf klicke, mache ich ein implizites Refresh, obwohl ich im Edit-Modus war (bin).
Das darf nicht sein.

Wieso soll man im Edit-Modus nicht Next/Prior klicken dürfen? Im Edit-Mode wird dabei vorher gepostet, es geht nichts verloren. Spart den Klick auf Post, wenn man gleich naschließend den folgenden/vorigen Record bearbeiten möchte.

Wenn das Verhalten des DBNavigator nicht dem entspricht, was du möchtest, mach dir halt einen eigenen. Es sind nur ein paar Buttons, die Standard-Methoden von TDataset aufrufen.

[Joh]

Zumindest, wenn man Autoedit auf false stehen hat,
den Datensatz explizit entsperrt
dann sollte nicht ein implizites speichern / verwerfen der Änderungen durch den Datensatzwechsel möglich sein.
IMHO.

Ich wollte jetzt auch nicht ReccordCount benutzen. Aber für mich war es ein Test, in wie weit sich das Verhalten nachvollziehen läßt. Noch bin ich Novize bei Lazarus, aber jemand, der zumindest weiß, welches Verhalten erwartbar ist. Weicht Lazarus davon ab, versuche ich zu ergründen, ob es an mir (irgendeine Eigenschaft flasch eingestellt), an Lazarus oder an der Datenbankumgebung liegt.

Oder an den vorhandenen Datenstrukturen: boolsche Variablen werden als Integer gesetzt:
Wert1: Integer = 0
Wert2: letztes Bit im Integer gesetzt
Wert3: vorletztes Bit im Integer gesetzt
...
und ich darf mich mit korrektem shiftleft herumschlagen. Dabei geht dann natürlich die Bindung der Felder an die Query kaputt, so das ich die eh manuell setzen muß. Aber das ist ein anderes Thema.