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?