RichEdit: Overridene SetSelStart-Methode wird nie aufgerufen

[TStringlist]

Das Ziel meiner Anstrengungen ist es, einen eigenen Caret zu installieren, ...einer der auch überall hinter einem Zeilenende frei positionierbar ist. Und da ich dessen Koordinaten in eigener Regie dann je nach Mausposition immer selbst berechnen muss und von dieser Caret/Mausposition aber selbst wieder etwaige Blockmarkierungen abhängig sind, wäre es also praktisch gewesen, diese durch die Maus entstehende Blockgenerierung dabei auch gleich selbst mit übernehmen zu können. ...Weil nämlich eine entsprechend systemerzeugte Blockgenerierung und die solches verursachende Mausbewegung so eine ganz speziell eigene Sache ist und eine aktuelle eigene Caret-Position damit dann natürlich auch immer harmonieren müsste.

Denn: Erzeuge mal in einem normalen RichEdit-Control mit der Maus einen mehrzeiligen Block und fahre mit dieser dann pixelweise nach oben, und zwar solange, bis du so dann irgendwann eine weitere Blockzeile erzeugt hast. Nun fahre mit der Maus wieder pixelweise herunter. Was siehst du? Eine Art von 'Unschärfe' (von bis zu 4 Pixeln) die jeweils immer wieder zusätzlich nach unten bzw. nach oben zu fahren ist, um den Block dann jeweils immer wieder neu um eine Zeile zu vergrößern bzw. verringern zu können. Und genauso wird natürlich auch keiner eine Position eines eigenen (künstlichen) Carets berechnen wollen! Und auch der Delphi-eigene Editor macht das nicht so, sondern der macht das natürlich so, wie ich das auch gerne hätte, nämlich ohne diesen 'Unschärfebereich'.


...Habe inzwischen aber doch noch einen theoretischen Lösungsweg gefunden (sofern sich nicht doch noch was einfacheres in Sachen Abfangen von WM-Messages bzgl. der oben erwähnten Situation ergeben sollte): Denn solange der Caret direkt auf einem Text steht und ich mich dort mit gedrückter linker Mousbutton bewege (also einen Block erzeuge), solange ist es nämlich auch gut möglich, mir dann einfach die system-eigenen Koordinaten der Blockgrenzen als Caret-Position aufzwingen zu lassen (da sie mir ja anfangs des MouseMove-Eventhandlers nun auch bekannt sind (wie ich das aber eben erst sehr kürzlich rausbekommen habe)). In allen übrigen Situationen benutze ich dann einfach wieder meine eigene jeweils selbst berechneten Koordinaten zur Caret-Positionierung. Wird wahrscheinlich auch gut so machbar sein, imho.

[Stevie]

Ok, ich hab - zugegebenerweise - überhaupt keine Ahnung, von der ganzen Caret-Geschichte, aber eine Frage stellt sich mir:
Wie willst du denn den Caret irgendwo hinter einer Zeile positionieren? Wahrscheinlich, indem du Leerzeichen bis zu dieser Position generierst, oder? Ist es dann nicht wieder so, dass es dann mit der RichEdit-Kompo gehen müsste?

Hab gerade mal Notepad genommen, da ist keine "Unschärfe" und dort müsste doch die WindowsRichEdit-Kompo benutzt werden oder?
Ich hab auch mal gehört, dass TRichEdit irgendwie nicht alles kann, was die WindowsRichEdit-Kompo kann?!

[TStringlist]

Nee, einen eigenen Caret (mit eigener Form und Farbe) installiere ich mittels DestroyCaret (zur Eliminierung des alten Carets) und einem anschließenden CreateCaret(..). Nützlich dafür sind außerdem z.B. auch noch solche Api-Funktionen wie SetCaretPos(..) und showCaret(..). So reduziere ich die Leerzeichen-Generierung nur auf die Situationen, in denen ich in solchen Positionen dann tatsächlich auch einen Text reinzuschreiben beginne.


Und soweit ich weiß ist Notepad nur auf einem TMemo aufgebaut, aber WordPad basiert auf einem RichEdit-Control ...und da ist es auch so wie ich es sagte.

[Stevie]

Zitat von TStringlist:

Und soweit ich weiß ist Notepad nur auf einem TMemo aufgebaut, aber WordPad basiert auf einem RichEdit-Control ...und da ist es auch so wie ich es sagte.

Klar, Notepad und RichEdit, wie doof!