[gelöst] Windows.DrawText oder Canvas.Textrect - keines tut, was es soll?

[PascalDragon]

@PacalDragon: Auch danke für die Info.
Dass man bei DrawText den Record mitgeben kann, hat mich schon gewundert - eben deshalb, weil es ja nur temporär sein kann. Obwohl - er wird dann ja doch an den Canvas übergeben. Der ganze Record lässt sich aber mühelos austauschen und damit scheint es dann doch ...? Wo ist da unterm Strich der Unterschied? Das Textstyle-Property verweist doch direkt nach FTextStyle mitten in TCanvas. Warum dann solche Restriktionen? Dadurch wird man nur dazu angeleitet, sich zur Vereinfachung Funktionen wie diese zu machen, die das ganze ›Sicherheitssystem‹ einfach aushebeln.

Es steht aber nirgendwo geschrieben, dass eine Eigenschaft auf ein Feld verweisen muss, es kann ja auch eine Funktion sein. Und wenn dir dann jemand unter der Haube das umändert (zum Beispiel wenn in der LCL jemand auf die Idee käme, dass eine Funktion sinnvoller wäre), dann hast du viel Spaß beim Debuggen. Oder wenn der Getter ein Feld, der Setter aber eine Funktion wäre: der Setter führt eventuell Konsistenzprüfungen durch, die bei einer direkten Änderung des Feldes umgangen würden. Deswegen wird das konsistent gehandhabt und schlichtweg verboten.

@wp_xyz: Danke, dann bin ich mal beruhigt, dass ich via winapi DrawText verwenden kann. Von der Windows-Unit werde ich also nachhaltig die Finger lassen.

Die Includedatei heißt nur deshalb WinAPI, weil sie verschiedene in Delphi gebräuchliche Funktionen der WinAPI in einer Cross Platform Variante bereitstellt. Das heißt jedoch nicht, dass sämtliche WinAPI Funktionen verfügbar sind (nur zur Sicherheit ).

[Jim Knopf]

Die Includedatei heißt nur deshalb WinAPI, weil sie verschiedene in Delphi gebräuchliche Funktionen der WinAPI in einer Cross Platform Variante bereitstellt. Das heißt jedoch nicht, dass sämtliche WinAPI Funktionen verfügbar sind (nur zur Sicherheit ).

Danke. Gut zu wissen, dass winapi ungefährlich ist. Wenn was fehlt, dann merke ich es eh.