 Frühlingsrolle hat folgendes geschrieben  : |
das Problem besteht nicht nur bei der Jedi-Komponente (TJvRichEdit), sondern auch bei der Standard-Komponente (TRichEdit).
Da beide den Vorfahren TCustomMemo haben, liegt das Problem entweder dort, oder beide Komponenten wurden mit dem selben "Fehler" erzeugt. |
Eine einfache behelfsmässige Lösung:
Delphi-Quelltext
1:
2:
3:
4:
5:
| procedure TForm1.JvRichEdit1ProtectChange(Sender: TObject; StartPos,
EndPos: Integer; var AllowChange: Boolean);
begin
AllowChange := True;
end; |
Das "True" sollte man natürlich durch einen boolschen Wert, der anhängig von irgendeiner Bedingung ist, ersetzen, sonst führt man Protected ja ad absurdum! Da es mir aber nur um die Eigenschaft
Protected als solche geht (ist gesetzt - ja/nein), ist mir das zunächst egal. Ich "missbrauche"
Protected nämlich, um einen Hyperlink im Text zu realisieren. Klickt man auf einen solchen Text, springt das Programm zu einer anderen Stelle im Text.
Dennoch ist es ein Bug, denn es müsste ja genügen,
SelAttributes.&Protected := False zu setzen.
Vielleicht baue ich den Jedi-Code noch um!
Noch eine Frage: Warum setzt Delphi da ein
& ein? Also statt
SelAttributes.Protected erweitert Delphi das zu
SelAttributes.&Protected.
//Edit: Ich sehe schon: Weil Protected ein reserviertes Wort ist.
gedunstig war's - und fahle wornen zerschellten karsig im gestrock. oh graus, es gloomt der jabberwock - und die graisligen gulpen nurmen!
