DBGRid fokusierte Zelle bei Verschiebung Scrollbalken

[Michl]

Hallo allerseits,

ich bin beim Feinschliff einer Anwendung. Dabei gefällt mir nicht, dass wenn man den vertikalen Scrollbalken eines DBGrids bewegt, automatisch die selektierte Zelle (Dataset.RecNo) mit verschoben wird. Gibt es dafür eine Option?! Konnte keine geeigneten finden (hoffentlich habe ich nur Tomaten auf den Augen) auch die Suchmaschine meiner Wahl war mir keine große Hilfe.

Gibt es eine Option/Eigenschaft oder eine Kombination dieser, die dieses Verhalten (so wie es bei OpenOffice "Calc" oder Excel zu finden sind) ermöglichen oder muss ich da selber vor dem Verschieben des Scrollbalkens die fokusierte Stelle (Dataset.RecNo) merken und diese danach wieder setzen (sofern ich das überhaupt so hinbiegen kann)?!

[Christian]

Vergisses.
Ich hab ein Konstrukt wo ich einfach nur nen Hint zum Datensatz anzeigen mag.
Dazu Disable ich das Grid, geht zum anderen Datensatz (unter der Maus) zeig den Hint
geh zurück und enable das Grid wieder.

Selbst das funktioniert nicht weil das Scrolling trotz deaktiviertem Grid gemacht wird.
Bugreport ist seit 2 Jahren offen.

[wp_xyz]

Bin nicht sicher, ob das zutrifft, aber ich habe dieses Verhalten (Scrollen des aktiven Records) schon bei Delphi-Anwendungen gesehen. Dann hatte ich einmal eine Anwendung, bei der das Scrollen des DBGrid plötzlich normal war. Letztendlich lag es daran, wie die Datenbank ans Grid angebunden ist. Stichwort: clientseitiger oder serverseitiger Cursor. Daher würde ich mal vermuten, dass, wenn du eine Memorytabelle zum Zwischenspeichern der Tabelle spendierst, das Verhalten des Grid normal ist. Vielleicht trifft das auch auf Lazarus zu.

[Christian]

Mag sein das Delphi das Verhalten auch an den Tag legt
trotzdem sollte nach Disablecontrols nichts mehr scrollen...
Siehe:http://docwiki.embarcadero.com/Libraries/XE5/de/Data.DB.TDataSet.DisableControls

[wp_xyz]

@Christian: Ich sollte besser zitieren, ich meinte eigentlich das Scrollen in Michls Posting.

[Michl]

Werde mal ein paar Testsprojekte machen und statt der DBGrid, mal eine StringGrid und eine DrawGrid probieren, die Tabelle dient mir ja nur zur Anzeige, die Bearbeitung der Daten mache ich ja schon extern. Werde auch mal einen DBGrid Hack probieren. Werde mich melden, wenn ich weitergekommen bin.

Danke an Euch erstmal für die Infos, sie beruhigen mich erst mal!

Bis dann,

Michael

[mse]

Ein dbgrid hat lediglich Zeilen für den sichtbaren Record-Bereich, der Puffer befindet sich dabei im TDataset. Der Record-Bereich im Puffer wird so eingestellt, dass er für das grösste angeschlossene Datengitter ausreicht und der aktive Datensatz sich im Fensterbereich befindet. Der Rollbalken im Gitter verschiebt also den Cursor im TDataset und damit auch das sichtbare Record-Fenster. Schau mal in TDataset.RecalcBufListSize(), TDataset.Resync() und TDatalink.ActiveRecord.

[Michl]

Danke für die Zusatzinfos! Ich muss mich da tatsächlich erst reinarbeiten, wird aber eine Weile dauern, da ich noch einige andere chirurgische Baustellen habe.

[mse]

Als Hinweis, die von MSEgui tmsebufdataset abstammenden DB-Komponenten haben die Möglichkeit auf alle Datensätze zuzugreifen ohne den DB-cursor zu verschieben (tmse*dataset.currentas* properties). Das wird z.B. benutzt, um in lookup-dropdown-Listen-Fenstern die Daten ohne scrollen des detail-dataset anzuzeigen (dropdown.optionsdb odb_directdata). Wahrscheinlich sollte ich diese Option auch für tdbwidgetgrid und tdbstringgrid implementieren.

[Michl]

Habe nun eine DrawGrid genommen, bestücke sie direkt per DataSetabfrage und bin 100%ig zufrieden damit.

Der Rollbalken im Gitter verschiebt also den Cursor im TDataset und damit auch das sichtbare Record-Fenster.

Ja, das habe ich nun verstanden...

Einen Patch zu erstellen für eine DBGrid, die genau das Verhalten zeigt, dachte ich sollte nicht so schwer sein. War es auch nicht. Eine Option "AktiveScroll" und ein paar Variablen á la "ScrolledRows" eingefügt und schon konnte man berechnen, wo das "ActiveRecord" sich in der Anzeige befindet. Ich war fast schon so weit, einen Patch hochzuladen, bis ich merkte, dass das ein ganz schöner Holzweg war, auf dem ich mich befand.
Das Problem war, dass ich den Record-Bereich weiterhin verschoben habe, nur die Position des aktiven Datensatzes künstlich angepasst habe. Damit passte zwar die Position des ActiveRecords nicht mit dem der Grid überein, das konnte ich vor jedem Zugriff auf die Tabelle korrigieren. Allerdings passen dann einige Events nicht mehr und ein Zugriff direkt auf das Dataset würde eine falsches (nicht das aktuell fokusierte) Record liefern. Ich gebe mich jetzt geschlagen. Für meine Anwendung ist die DrawGrid ein sehr guter Ersatz. Danke mse, für die Hinweise, die Du mir zuvor gegeben hattest, in Ihrer Tragweite kann ich sie erst jetzt nachvollziehen.

[mse]

Ich werde auch in MSEgui das "directdata" Prinzip nicht auf allgemeine DB-Datengitter ausweiten, es verträgt sich nicht mit den fkCalculated Feldern. Für die Anzeige von DB-Daten in normalen Gittern hat MSEgui ja das IfI-System.