![]() |
VirtualStringTree, CellPaint und der grafische Offset
Liste der Anhänge anzeigen (Anzahl: 1)
Hallo!
Ich bastle derzeit an einem neuen VST-Descendant und stehe dabei (wie schon einige Male in der Vergangenheit) vor folgendem Problem: Einige Zeichenroutinen wie z.B. OnAfterCellPaint übergeben ein eigenes Canvas-Objekt und ein CellRect. Dabei bildet der VST sozusagen ein mehrfach virtuelles Koordinatensystem, das mir regelmäßig Kopfzerbrechen bereitet.
Delphi-Quellcode:
Dabei bildet TargetCanvas lediglich das Rechteck des jeweiligen Nodes ab, CellRect dann das Rechteck der mit Column angegebenen Spaltenzelle. Den horizontalen Offset relativ zu Tree.ClientRect bekomme ich notfalls über Header.Columns[n].Width heraus. Allerdings finde ich wirklich keine Möglichkeit, den vertikalen Offset relativ zu Tree.ClientRect zu bestimmen. Zur Verdeutlichung ein kleines Kunstwerk im Anhang...
procedure TForm1.TreeAfterCellPaint(Sender: TBaseVirtualTree;
TargetCanvas: TCanvas; Node: PVirtualNode; Column: TColumnIndex; CellRect: TRect); begin // ... end; Relevant wird das Ganze, wenn man Mausereignisse innerhalb einer Zelle abfangen will, weil dort OwnerDraw-Elemente vorhanden sind die interaktive Mausbedienung ermöglichen sollen. Dann muss ich von den globalen Mauskordinaten auf die relativen Control-Koordinaten (ClientToScreen und umgekehrt) herunter rechnen, komme dann aber mit den weiteren "Unter-Koordinatensystemen" nicht weiter weil ich nicht ermitteln kann, wo sich der aktuelle Node im Viewport befindet. Grüße Cody |
AW: VirtualStringTree, CellPaint und der grafische Offset
Ich habe dein Problem nicht 100%ig verstanden und kann deshalb nur mit den Informationen arbeiten, die ich aus deinem Post herauslesen konnte. Hierzu die Frage: Hilft dir die
Delphi-Quellcode:
Funktion weiter?
vst.GetDisplayRect(Node: PVirtualNode; Column: TColumnIndex; TextOnly: Boolean; Unclipped: Boolean = False; ApplyCellContentMargin: Boolean = False): TRect;
Im Source des VST lese ich folgendes:
Delphi-Quellcode:
function TBaseVirtualTree.GetDisplayRect(Node: PVirtualNode; Column: TColumnIndex; TextOnly: Boolean;
Unclipped: Boolean = False; ApplyCellContentMargin: Boolean = False): TRect; // Determines the client coordinates the given node covers, depending on scrolling, expand state etc. // If the given node cannot be found (because one of its parents is collapsed or it is invisible) then an empty // rectangle is returned. // If TextOnly is True then only the text bounds are returned, that is, the resulting rectangle's left and right border // are updated according to bidi mode, alignment and text width of the node. // If Unclipped is True (which only makes sense if also TextOnly is True) then the calculated text rectangle is // not clipped if the text does not entirely fit into the text space. This is special handling needed for hints. // If ApplyCellContentMargin is True (which only makes sense if also TextOnly is True) then the calculated text // rectangle respects the cell content margin. // If Column is -1 then the entire client width is used before determining the node's width otherwise the bounds of the // particular column are used. // Note: Column must be a valid column and is used independent of whether the header is visible or not. begin [...] end; |
AW: VirtualStringTree, CellPaint und der grafische Offset
Zitat:
|
AW: VirtualStringTree, CellPaint und der grafische Offset
Zitat:
|
AW: VirtualStringTree, CellPaint und der grafische Offset
Der VST ist eben auch ein verdammt umfangreiches Ding geworden. Die Art wie der seinen Viewport pinselt ist zwar sehr effizient aber eben auch sehr komplex zu handhaben wenn man versucht, abgeleitete Komponenten zu bauen. In dem Fall könnte man auch sagen, man sieht den VirtualStringTree vor lauter Zweigen nicht ^^
|
AW: VirtualStringTree, CellPaint und der grafische Offset
Da hast du wohl recht. Ich habe mich zwar sehr sehr intensiv mit dem VST auseinandergesetzt und auch schon einige Programme geschrieben die auf dem VST aufbauen, aber trotzdem findet man immer mal wieder etwas neues heraus. Die Programme waren eben sehr komplex (was das Zeichnen des VST anging), weshalb ich auch die Tiefen des VST erkunden musste. :-D
Generell gilt bei der Komponente: Der Source ist deine beste Hilfe um neue Dinge zu entwickeln oder auch Fehler zu finden. Zusätzlich kann man sich noch die von Mike Lischke bereitgestellte PDF Datei anschauen. Die ist umfangreicher als die CHM Datei. Schade nur, dass keines der beiden von Jam Software weitergeführt wird/wurde. :( |
Alle Zeitangaben in WEZ +1. Es ist jetzt 17:29 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz