Danke Allen fürs Antworten.
Zitat von
Der_Unwissende:
Warum genau benutzt du denn Perform? Kenne diese Funktion jetzt nicht so wirklich von ihrer Benutzung, aber ich denke, dass du hier vielleicht genau den Fehler drin hast, den du nicht möchtest
Mit dieser Methode kann man der WindowProc des Controls direkt eine Window-Message zukommen lassen, ohne über die sonst übliche Botschaftswarteschlange von Windows gehen zu müssen. Man könnte hier also auch genauso gut die
Api-Funktion "SendMessage" fürs Versenden solcher Messages benutzen, was dann allerdings auf das Gleiche herauskäme (und hier auch das gleiche Ergebnis hervorbringt).
Zitat von
Der_Unwissende:
denke mal, dass ein Lines.Add schon getestet wurde und sicher funktioniert
Die Zeile verursacht den Fehler ja nicht eigentlich, sondern sie löst die
Exception quasi nur aus. Wenn man diese Zeile weglässt, wird der Fehler ja auch schon ziemlich deutlich (siehe das angehängte Bild). Und groß versteckt kann die Verursachung auch nicht irgendwie sein, denn die Procedure ist ja sozusagen schon das ganze Programm.
Zitat von
Lannes:
der Fehler ist abhängig vom Betriebssystem bzw. eher von der genutzten riched32.dll
Also mein PC läuft unter
W2k, da heißt es doch immer "auf NT-Technologie basierend", oder läuft
W2k auch mit der RichEd20.dll?
Ich habe jetzt mal beide DLLs hintereinander ins Anwendungsverzeichnis kopiert, die
Exception allerdings blieb. Aber selbst wenn es bei einer
DLL keine
Exception gäbe, wenn man das Prog mal weitergeben wollte, dann müsste man diese
Dll wohl immer mit ins Anwendungsverzeichnis mit hineinkopieren?
@teebee
Durch das Lines.Add wird die
Exception nur ausgelöst. Der dieser zugrunde liegende Fehler wird allerdings schon vorher irgendwie verursacht. Mit deinen Zeilen tritt die
Exception bei mir auch nicht mehr auf (auch z.B. mit Lines.Text:=Lines.Text+'bla' nicht), aber der im Bildanhang angezeigte Fehler taucht damit trotzdem noch auf.