TDBGrid mit Scrollrad aufmöbeln
Stefan M. Huber
Ich hab gestern in der Arbeit ein TDBGrid abgeleitet, das das Handling
des Scrollrades verbessert (Scrollen auch weiter als nur im sichtbaren
Bereich). Grob gesagt mach ich das:
SCROLLWHEEL-Message abfangen und je nach Delta ein CursorDown oder
CursorUp schicken, sowie die Nachricht als abgehandelt behandeln.
Inherited wird nur aufgerufen, sollte das Delta==0 sein (gibts das
überhaupt, außer bei künstlich generierten Nachrichten?)
Die Fragen, die sich mir stellen: Ist das eigentlich böse[0]? Sollte man
eventuell anders das Scrollen auslösen (zB mit next oder previous-Methoden
für das DataSet?)
Und warum ist das nicht eigentlich schon in der TDBGrid Implementierung so
vorgesehen? Naja, das kann man ja ändern :)
Ich hab mich mal durch den Ast an Klassen gehangelt, von WM_MOUSEWHEEL
zurück und über CM_MOUSEWHEEL wieder vorwärts, bis ich bei
TCustomGrid.DoMouseWheelUp/Down gelandet bin. Dort steht:
Result := inherited DoMouseWheelDown(Shift, MousePos);
if not Result then
begin
if Row < RowCount - 1 then Row := Row + 1;
Result := True;
end;
Also geht der auf den RowCount los (Ich hätte mich hier um
DataSource.DataSet gestürzt; im Experimentalfall mal einfach ein Next und
Prior). Und setzt in jedem Fall das Result auf true. Gemein. Also bleibt
nichts übrig, als sämtliche DoMouseWheel Handler in die abgeleitete
Komponente zu übernehmen, oder dbgrids.pas zu ändern. Igitt. Andere Ideen?
Stefan
[0] Ich denke da an OnKeyDown events; konnte aber in den paar Minuten vorm
Gehen aus der Arbeit keine Seiteneffekte feststellen.
--
BUGS: None. Mutts have fleas, not bugs.
--- taken from the mutt manpage
Michael Winter
> Ich hab gestern in der Arbeit ein TDBGrid abgeleitet, das das Handling
> des Scrollrades verbessert (Scrollen auch weiter als nur im sichtbaren
> Bereich). Grob gesagt mach ich das:
> SCROLLWHEEL-Message abfangen und je nach Delta ein CursorDown oder
> CursorUp schicken, sowie die Nachricht als abgehandelt behandeln.
Du meinst die Runter- und Hoch-Tasten? Ich würde das nicht so machen.
Setze in einem Texteditor die Schreibmarke in die Mitte der Seite und rolle
mit dem Mausrad. Die Schreibmarke bleibt im gleichen Wort.
Auch bei einem Grid würde ich erwarten, das die gewählte Zelle aktiv
bleibt. Ergo eher das gleiche Ergebnis wie beim Verschieben des vertikalen
Rollbalkens. Erreichen kannst du das, indem du WM_VSCROLL an das
(Grid-)Fenster schickst.
> Inherited wird nur aufgerufen, sollte das Delta==0 sein (gibts das
> überhaupt, außer bei künstlich generierten Nachrichten?)
Keine Ahnung. Ich glaube ich wäre da weniger zimperlich: Wenn ich die
Nachricht komplett bearbeite (und dazu gehört Nicht-Scrollen bei Delta =
0), dann geht sie inherited nichts mehr an.
> Die Fragen, die sich mir stellen: Ist das eigentlich böse[0]? Sollte man
> eventuell anders das Scrollen auslösen (zB mit next oder previous-Methoden
> für das DataSet?)
Letzteres würde mir noch weniger gefallen. Das würde zum Beispiel die
Methode unbrauchbar für ein (Nicht-DB-)Stringgrid machen.
-Michael
Stefan M. Huber
wrote:
> Stefan M. Huber schrieb:
>
>> Ich hab gestern in der Arbeit ein TDBGrid abgeleitet, das das
>> Handling
>> des Scrollrades verbessert (Scrollen auch weiter als nur im sichtbaren
>> Bereich). Grob gesagt mach ich das:
>> SCROLLWHEEL-Message abfangen und je nach Delta ein CursorDown oder
>> CursorUp schicken, sowie die Nachricht als abgehandelt behandeln.
>
> Du meinst die Runter- und Hoch-Tasten? Ich würde das nicht so machen.
>
> Setze in einem Texteditor die Schreibmarke in die Mitte der Seite und
> rolle mit dem Mausrad. Die Schreibmarke bleibt im gleichen Wort.
Guter Punkt. Aber in Grids ist das Verhalten so, dass der nächste/vorige
Datensatz angezeigt wird. Also von dem her würde ich das nicht als
Erwartungsbruch sehen.
> Auch bei einem Grid würde ich erwarten, das die gewählte Zelle aktiv
> bleibt. Ergo eher das gleiche Ergebnis wie beim Verschieben des
> vertikalen Rollbalkens. Erreichen kannst du das, indem du WM_VSCROLL an
> das
> (Grid-)Fenster schickst.
Ist wahrscheinlich das ungefährlichste, da hast du recht. Ich muss das mal
probieren.
>> Inherited wird nur aufgerufen, sollte das Delta==0 sein (gibts das
>> überhaupt, außer bei künstlich generierten Nachrichten?)
>
> Keine Ahnung. Ich glaube ich wäre da weniger zimperlich: Wenn ich die
> Nachricht komplett bearbeite (und dazu gehört Nicht-Scrollen bei Delta =
> 0), dann geht sie inherited nichts mehr an.
Klingt vernünftig. Doch wenn man nicht weiß, ob Delta==0 einne Sinn macht,
frägt man lieber nach.
>> Die Fragen, die sich mir stellen: Ist das eigentlich böse[0]? Sollte man
>> eventuell anders das Scrollen auslösen (zB mit next oder
>> previous-Methoden
>> für das DataSet?)
>
> Letzteres würde mir noch weniger gefallen. Das würde zum Beispiel die
> Methode unbrauchbar für ein (Nicht-DB-)Stringgrid machen.
Stimmt. Aber entsinne ich mich nicht richtig, dass beim StringGrid sowieso
das Scrollen funktioniert, weil es seinen RowCount immer kennt? Das ist ja
anscheinend der springende Punkt, vor allem bei ADO Verbindungen: Rowcount
steht erst fest, wenn man alles durch hat. Zumindest interpretiere ich den
Unterschied zwischen StringGrid und DBGrid genau da.
Dennoch gefällt mir die Idee mit den Scroll-Messages sehr gut. Ist halt
die Frage, was man sich wirklich bei einem Grid erwartet; ob Prior/Next
oder einfach nur scroll.
Danke dir,
Stefan
--
Pieces of eight...Squawk...Pieces of eight...
Squawk...Pieces of Nine...Squawk!...Parroty Error!