RichEdit: Overridene SetSelStart-Methode wird nie aufgerufen

[TStringlist]

Ja, das hatte ich auch vorher die ganze Zeit schon über versucht, ...scheint hier aber irgendwie nicht so richtig möglich zu sein. So wie ich jetzt erst festgestellt habe, scheint das RichEdit diese Blockerzeugung auch gar nicht (in eigenen Routinen) selbst abzuwickeln, sondern ein solches (system-intern erzeugtes) Resultat wieder nur mit EM_EXGETSEL abzugreifen. Jedenfalls können die nach einer Mausbewegung jeweils neuen Blockgrenzen dann auch immer gleich schon zu Beginn des MouseMove-Eventhandlers so einfach ausgelesen werden, und zwar eben höchstwahrscheinlich vom System schon entsprechend aktualisiert. Denn selbst wenn ich während eines Mousemovings alle auftretenden EM_EXSETSEL- oder EM_SETSEL-Messages abfische, ändert sich daran nichts ...weil eine system-basierende Blockerzeugung und Anzeige dieser Markierung dadurch ja auch nicht unterdrückbar ist (...sondern nur eine event. eigene nämlich selbst durch EM_EXSETSEL verursachte Festlegung neuer Blockgrenzen). Bliebe folglich also nur noch mehr das eigentliche Anzeigen dieses systemdefinierten Blockes zu verhindern, etwa durch ein Abfangen von WM_Paint-Messages.

Dadurch aber, dass ich ja jeweils auch immer diese Blockgrenzen selbst neu errechne und dann mittels EM_EXSETSEL noch eingebe und das wiederum zeitlich sehr dicht an der entsprechend äquivalenten Aktion des Systems angesiedelt ist, wird die Sache auch nicht gerade einfacher. Es ist nämlich ziemlich schwierig die durchs System entsprechend verursachten WM_Paint-Messages abzufischen und die unmittelbar danach selbst verursachten durchzulassen ...einschließlich einem dazu noch nötigen korrekten Management der dabei auch noch zahlreich mit dazu auftretenden WM_ERASEBKGND-Messages.


(...Und als ich nun gestern schon so in diesem ganzen Schlamassel herumwadete, da suchte ich natürlich nach einfacheren Lösungen und machte also zuerstmal diesen Thread hier auf... *ggg*)