RichEdit: Overridene SetSelStart-Methode wird nie aufgerufen

[TStringlist]

Hallo!

In einer eigenen TMyRichEdit-Klasse habe ich die beiden von TCustomRichEdit abstammenden Methoden "SetSelStart(..)" und "SetSelLength(..)" überschrieben. Jetzt wundere ich mich allerdings einigermaßen, warum die Programm-Abarbeitung in diesen Routinen scheinbar nie vorbeikommt (bzw. dort anhält, nachdem ich z.B. dort jeweils einen Breakpunkt reingesetzt habe). Hat eventuell jemand eine Idee, woran das liegen könnte?

Delphi-Quellcode:

  TMyRichEdit = class(TRichEdit)
  private
    fLButtonDown : boolean;
    ... 
  protected
    ...
    procedure SetSelLength(Value: Integer); override;
    procedure SetSelStart(Value: Integer); override;
  public
    ...
  end;

...

Procedure TMyRichEdit.SetSelStart(Value: Integer);
begin
  // Weil: Wenn fLButtonDown=TRUE mache ich diese Arbeit anderswo selbst!
  if not fLButtonDown then inherited;
end;

Procedure TMyRichEdit.SetSelLength(Value: Integer);
begin
  // Weil: Wenn fLButtonDown=TRUE mache ich diese Arbeit anderswo selbst!
  if not fLButtonDown then inherited;
end;

Thx schonmal im Voraus

[Stevie]

Du musst auch noch die Property überschreiben, denn im TRichEdit (wo die überschriebenen Methoden ja vorkommen) ist ja nicht bekannt, dass sie überschrieben wurde, also:

Delphi-Quellcode:

TMyRichEdit = class(TRichEdit)
private
  fLButtonDown : boolean;
  ...
protected
  ...
  procedure SetSelLength(Value: Integer); override;
  procedure SetSelStart(Value: Integer); override;
public
  property SelLength: Integer read GetSelLength write SetSelLength;
end;

[TStringlist]

Thx, aber eben sehe ich erst, dass ich das Problem noch nicht vollständig beschrieben hatte. Denn: Wenn ich SelStart bzw. SelLength direkt per Code lade, dann wurden/werden diese Routinen schon aufgerufen. Nicht aufgerufen werden sie aber leider dann, wenn diese beiden Größen z.B. aufgrund einer Maus-Aktion einen Wert zugewiesen bekommen müssten, weil mittels der Maus eben der Caret neu gesetzt bzw. ein Block markiert wurde. ...und nur auf das Manipulieren einer solchen Maus-verursachten Situation kommt es mir eigentlich an.


Ergo folgere ich schon mal: Wenn diese Property-Routinen also normal funktionieren (wie festgestellt), in der mir wichtigen Situation aber nicht angesprochen werden, dann scheint diese Arbeit wohl in noch anderen Methoden abgewickelt zu werden,

...und wo diese Werte dann wahrscheinlich gleich in den jeweilig diesbezüglichen Feld-Variablen (etwa fSelStart/fSelLength) abgelegt werden,

...und womit man das dann wahrscheinlich selbst wieder nicht überschreiben könnte,

oder?

[Stevie]

Jepp, da hast du recht! Bleibt dir nur die Möglichkeit, TRichEdit komplett zu kopieren und dort deine Änderungen vorzunehmen.

[TStringlist]

hmmm, es würde mir ja schon genügen, wenn man einfach nur diese Eigenschaft des RichEdits, nämlich einen Block mit der Maus zu markieren, irgendwie unterdrücken, ausschalten, blockieren... könnte. Das kann doch nicht unmöglich sein? (Oder ist das Ganze etwa systemgesteuert und das RichEdit greift dann das SelStart/SelLength-Ergebnis einfach nur noch mehr mit irgendwelchen EM_EXGETSEL-Funktionen ab, z.B. in der MouseMove-Proc o.ä...)?

...aber was meinst du eigentlich mit "TRichEdit komplett kopieren"? Meine TMyRichEdit-Klasse baut doch direkt auf der normalen TRichEdit-Klasse auf, beinhaltet diese also komplett.. (?)

[Stevie]

Genau das ist das Problem: du musst etwas in den Funktionen ändern, die in TRichEdit gekapselt sind und nicht vererbt werden können, weil sie teilweise private sind. Deshalb musst du das TRichEdit neu bauen (kopieren) und dann an den entscheidenden Stellen deine Veränderungen vornehmen. Du baust also nicht auf TRichEdit auf, sondern baust eine neue Komponente (evtl. musst du sogar TCustomRichEdit auch neu bauen), die das gleiche - bis auf ein paar Modifikationen - wie TRichEdit.

[TStringlist]

...ggf. alles auch ab TCustomEdit (oder sogar noch eins früher) nachbauen sieht allerdings seeeeehr seeeeeeeeeehr arbeitsintensiv aus *g*. Oder man bräuchte 'ne Enterprise-Version, und könnte darin mal kurz nachgucken, wie die das z.B. auch bzgl. meiner Fragen da erledigt haben...

However, Thx jedenfalls, aber eventuell hat ja noch jemand eine Idee, wie man dieses mausmäßige Blockgenerieren unterdrücken kann.

[Stevie]

Wenn's darum geht, dann müsstest du in deiner Klasse die nötigen Windows-Botschaften selber behandeln.

[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*)

[Stevie]

Zitat:

Zitat von TStringlist

(...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*)

Und was wird dir hier als Lösung angeboten? :arrow: Zurück in den Schlamassel!!! :mrgreen:

Was versuchst du denn überhaupt? Willst du die Mausmarkierung manipulieren? Wozu soll das denn gut sein?

[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:

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.

:wall: Klar, Notepad und RichEdit, wie doof! :roll: :oops: