EOutOfResources: 'Fehler bei Einfügen von RichEdit -Zeile'

[TStringlist]

Hi,

ich habe hier mal eine solche EOutOfResources-Exception, welche imo durch einen RichEdit-internen Fehler verursacht wird, reduplizierbar gemacht. Was mich daran jetzt u.a. interessieren würde ist, ob diese Exception mittels der folgenden Proc auch überall (also auf jedem PC) erzeugbar ist oder ob sich deren Auftauchen event. auch irgendwie noch etwas system- bzw. umgebungsabhängig verhält.


Hier also der Exception-Erzeugungs-Code (nötig dazu: 1*RichEdit, 1*Button, 2*Labels):

Delphi-Quellcode:

procedure TForm1.Button1Click(Sender: TObject);
var I : integer;
    AStr : String;
begin
  RichEdit1.Perform(EM_SetLimitText,$7ffffffe,0); // ist aber unnötig, da Text < 64KB

  with RichEdit1 do begin
    RichEdit1.Clear;
    AStr := '---------------------';
    RichEdit1.Lines.Add(AStr + '--------------');
    for I := 1 to 2440 do RichEdit1.Lines.Add(AStr);


    Lines.Insert(0,'on:   ' + '00:00:00  ');
    Lines.Insert(2,'on:   ' + DateToStr(Now) + '  00:00');
    Lines.Insert(3,'on:   ' + DateToStr(Now) + '  24:00              00:00:00');


    SelStart := Perform(EM_LINEINDEX,3,0) + 37; // = Position des '00' in Zeile3
    SelLength := 2;
    SelText := '24'; // Austausch der ersten '00' durch ein '24'


    Label1.Caption := 'Chars = ' + IntToStr(Length(Lines.Text));
    Label2.Caption := 'Lines = ' + IntToStr(Lines.Count);
    Lines.Add('bla bla'); // <=== hier wird die Exception ausgelöst
  end;
end;

Im angehängten Bild befindet sich noch ein kleiner Screen-Shot vom Programm-Output für denjenigen Fall, bei dem die letzte Lines-Add()-Zeile im Code weggelassen wird (also z.B. mit Comment-Slashes davor). Dann tritt zwar keine Exception mehr auf, aber das dann angezeigte Endergebnis ist fehlermäßig auch ziemlich lustig.


Event. checken ja ein paar von euch mal kurz, ob diese Exception auf eurem Rechner ebenfalls eintritt. Auf meinem PC ist der Fehler jedenfalls beliebig wiederholbar. Und da der Code in allen Teilen eigentlich auch mehr oder weniger üblich ist, sieht das Ganze meines Erachtens also irgendwie schon nach einer echten Fehlfunktion des RichEdit-Controls aus. Eine, die dann natürlich auch immer und überall mal auf einen lauern könnte ...und wodurch das RichEdit doch auch eigentlich schon irgendwie unbrauchbar würde, oder?


Oder irre ich da etwa irgendwo??? Ansonsten bräuchte man für Progs, die man auch irgendwie mal etwas weitergeben möchte, dann doch wohl ein alternatives (fehlerloses) Text-Control. Eines, das zum RichEdit zwar möglichst kompatibel ist (zwecks einfachem Austausch in bisherigen Progs), welches aber auch wieder nicht davon abgeleitet sein sollte?


Was ich nicht brauche sind Tipps, mit denen ich den Error nur vordergründig etwas "wegdrücken" kann. Interessant wäre aber, was man gegen eine solche Fehlermöglichkeit prinzipiell tun könnte, um sie mit Sicherheit auszuschließen.


Thx im Voraus.


PS. Oder sollte man die Exception event. immer mit der Meldung abfangen: "Sorry, kleine Fehlfunktion des RichEdit-Controls, die Schuld dafür suchen Sie bitte bei der Firma Micro-Soft" ?

[Der_Unwissende]

Also ich weiß nicht, ob das wirklich ein Fehler von Winzigweich ist. 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.
Hatte auch mal ein Problem mit EOutOfRessource (bei einer selbsterstellten Tiff-Komponente). Da war es dann wirklich ein Speicherleck, dass zwar gar nicht so hektisch wirkte aber ziemlich schnell alle Systemressourcen verbraten hat (auf nem 3Ghz 64 Bitter, mit 2 GByte Ram, was halt schnelles System aber nicht mehr Systemressourcen bedeutet). Hatte meinen Fehler nur so gut versteckt, dass ich echt ein Weilchen suchen durfte. Also denke ich mal, dass der Fehler nicht allein durch die Zuweisung kommt, denke mal, dass ein Lines.Add schon getestet wurde und sicher funktioniert.
Möchte auch nicht sagen, dass du Unrecht hast, sicherlich macht MS genug Fehler (wer nicht?) aber die Wahrscheinlichkeit für unentdeckte Fehler ist halt doch geringer als für Eigene (zumindest bei mir).

Gruß Der Unwissende

[Lannes]

Hallo,

der Fehler ist abhängig vom Betriebssystem bzw. eher von der genutzten riched32.dll,
bei XP wird ja darin auf die riched20.dll verlinkt.

Unter NT tritt der Fehler nicht auf,
dort wird eine ältere riched32.dll genutzt.

Sobald man die riched32.dll und riched20.dll aus XP
in das Verzeichnis der Anwendung auf den NT-Rechner kopiert,
wird auch dann die Exception ausgelöst.

Also eine alte riched32.dll ins Anwendungsverzeichnis kopieren,
dann ist der Fehler zumindest nicht mehr vorhanden.
Dann fehlen Dir aber die Funktionen die riched20 bietet. :?

[teebee]

Bei mir tritt der Fehler auch auf. Habe etwas im Internet geforscht, anscheinend hat es mit dem Gebrauch von Lines.Add zu tun (Ich weiss allerdings nicht, wo das Problem genau liegt). Es wird ein Workaround beschrieben, der bei mir funktioniert:

Delphi-Quellcode:

// statt Lines.Add:

RichEdit1.SelStart := RichEdit1.GetTextLen;
RichEdit1.SelText := ('bla bla bla')+#13#10;

SelStart wird von SelText automatisch angepasst und muss nur einmal zu Beginn einer Serie von Anfügungen aufgerufen werden.

Gruß, teebee

[TStringlist]

Danke Allen fürs Antworten.

Zitat:

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:

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:

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? :roll:


@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.

[teebee]

Ich habe Deinen Code so verändert, und das Ergebnis sieht zumindest so aus, als könnte es hinkommen:

Delphi-Quellcode:

  with RichEdit1 do begin
    RichEdit1.Clear; 
    AStr := '---------------------'; 
    RichEdit1.Lines.Add(AStr + '--------------'); 
    Richedit1.SelStart := RichEdit1.GetTextLen;
    for I := 1 to 2440 do RichEdit1.SelText := AStr+#13#10;

    RichEdit1.SelStart := 0;
    Richedit1.SelText := 'on:   ' + '00:00:00  '+#13#10+#13#10;

    Richedit1.SelText := 'on:   ' + DateToStr(Now) + '  00:00'+#13#10;
    Richedit1.SelText := 'on:   ' + DateToStr(Now) + '  24:00              00:00:00'+#13#10;


    SelStart := Perform(EM_LINEINDEX,3,0) + 37; // = Position des '00' in Zeile3
    SelLength := 2;
    SelText := '24'; // Austausch der ersten '00' durch ein '24'


    Label1.Caption := 'Chars = ' + IntToStr(Length(Lines.Text));
    Label2.Caption := 'Lines = ' + IntToStr(Lines.Count);
    RichEdit1.SelStart := RichEdit1.GetTextLen;
    RichEdit1.SelText := ('bla bla bla')+#13#10;
//    Lines.Add('bla bla'); // <=== hier wird die Exception ausgelöst
  end;

Gruß, teebee

[Lannes]

Hallo,

Zitat:

Zitat von TStringlist

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?

kA, aber das kannst Du doch feststellen. Im System oder sytem32-Verzeichnis findest Du die beiden dll's. Die Riched32.dll hat dann nur noch eine Größe von 4Kb.

Der Fehler wird ursächlich ausgelöst durch Insert an Zeile 0.
Daher wird auch die '24' an die falsche Stelle geschrieben, nehme an das die eingefügten Zeilen wegen dem Fehler dann nicht mitgerechnet werden(können?).
Fügt man eine Zeile tiefer ein dann gibt es keinen Fehler.

Delphi-Quellcode:

//Lines.Insert(0,'on:   ' + '00:00:00  '); 
Lines.Insert(1,'on:   ' + '00:00:00  ');
Lines.Insert(2,'on:   ' + DateToStr(Now) + '  00:00'); 
Lines.Insert(3,'on:   ' + DateToStr(Now) + '  24:00              00:00:00');

was machen ? Nie an Index 0 eine Zeile mit Insert einfügen.

[TStringlist]

Zitat:

Zitat von teebee

Delphi-Quellcode:

...
RichEdit1.SelStart := 0;
Richedit1.SelText := 'on:   ' + '00:00:00  '+#13#10+#13#10;

Richedit1.SelText := 'on:   ' + DateToStr(Now) + '  00:00'+#13#10;
Richedit1.SelText := 'on:   ' + DateToStr(Now) + '  24:00              00:00:00'+#13#10;
...

Durch diese Code-Sequenz baust du aber den Text insgesamt falsch auf, und nur deswegen tritt der Fehler dann nicht mehr auf. Die ursprünglich nullte '-----'-Zeile (index-mäßig) muss ja nachher auf der Indexposition 1 rauskommen. Und die beiden anderen Zeilen werden dann darunter eingefügt. Richtig müsste diese betroffene Code-Stelle also so aussehen:

Delphi-Quellcode:

RichEdit1.SelStart := 0;
Richedit1.SelText := 'on:   ' + '00:00:00  '+#13#10;
SelStart := Perform(EM_LINEINDEX,2,0); 
Richedit1.SelText := 'on:   ' + DateToStr(Now) + '  00:00'+#13#10;
Richedit1.SelText := 'on:   ' + DateToStr(Now) + '  24:00              00:00:00'+#13#10;

...und dann tritt der Fehler eben doch wieder auf. Die Exception zwar nicht, weil du ja keinerlei Lines.Add mehr machst, aber den Output-Fehler gibt's trotzdem.

Zitat:

Zitat von Lannes

kA, aber das kannst Du doch feststellen. Im System oder sytem32-Verzeichnis findest Du die beiden dll's. Die Riched32.dll hat dann nur noch eine Größe von 4Kb.

Stimmt! Sie hat nur 4KB. Also haben die den Fehler tatsächlich in dieser neueren RichEd20.dll eingebaut. Tsss, kaum zu glauben. Und davon ist jetzt die ganze Welt abhängig :pale: :mrgreen:

Zitat:

Zitat von Lannes

Der Fehler wird ursächlich ausgelöst durch Insert an Zeile 0.

Stimmt leider nicht. Wenn ich die ganzen Lines.Insert-Zeilen alle gleichmäßig eins nach oben zielen lasse und mit SelText dann auch entsprechend Zeile 4 ändere, dann haben wir wieder das fast gleiche Fehlerbild wie vorher. Dort im Code jetzt jeweils nur irgend eine Kleinigkeit zu ändern, ist quasi immer nur so eine Art von "wegdrücken" des Errors, der nämlich nur aufgrund ganz bestimmter Konstellationen eintritt. Ändere ich die irgendwo nur minimal, dann ist es durchaus wahrscheinlich, dass auch dieser Error weg ist. Die Möglichkeit eines solchen Errors jedoch, wenn diese Bedingungen dann irgendwann mal wieder zufällig genau so eintreten sollten, bleibt aber natürlich leider.

[teebee]

Merkwürdigerweise funktioniert alles prima, wenn Du nur bis 2134 gehst. Dann geht auch Lines.Add. Mit einem einfachen Memo geht auch alles gut. Sehr seltsam....

Viel Erfolg noch,
teebee

[TStringlist]

@teebee

>> Sehr seltsam....

Echt!

Letztlich wird der Grund dafür aber wahrscheinlich schon ein kleiner Fehler in dieser RichEd20.dll sein. Ein Memo wird dessen Funktionen zwar ebenfalls benutzen (oder?), hat aber intern wohl auch eine etwas andere Speicherorganisation (es hat ja z.B. auch nicht diesen internen {\rtf1...-Code zu verwalten). Na ja, eventuell wird ja diese DLL bei irgendeinem nächsten Servic-Pack dann auch mal mit erneuert :stupid:. Thx jedenfalls nochma.