| Autor |
Beitrag |
DarkPhenix
Hält's aus hier
Beiträge: 10
WIN XP, WIN Vista
Delphi 7, Delphi 2009, JBuilder 2008, Visual Studio 2008, C++ Builder 2009
|
Verfasst: Fr 06.02.09 15:16
Hey!
Ich hab in meinem Programm ein PageControl mit 2 Tabsheets eingefügt. In den Tabsheets siehts recht gleich aus (gleiche Komponenten, aber andere Funktion). Wenn ich nun das Programm starte (Delphi 7, Aktiver TabSheet ist der 2te) und dann vom 2. Tabsheet in den ersten wechsel kommt der Fehler:
EOutOfResources: "Für diesen Befehl ist nicht genügend Speicher verfügbar".
Starte ich mit aktiven TabSheet 1 ist das kein Problem und ich kann zum nächsten Tabsheet wechseln UND auch wieder zurück! Dabei entsteht keinerlei Fehler.
Ich rufe beim wechseln keine Function o.ä. auf, er soll einfach den anderen TabSheet zeigen.
Ich hab in OnChange ein sleep(1) eingefügt und den Haltepunkt dort gesetzt, dahin kommt er, danach kommt sofort der Fehler (mehr als sleep(1) steht in OnChange nicht drin).
Ich weiß echt nicht, wieso der Fehler kommt...ist recht ärgerlich.
Als Test habe ich auch noch nen drittes TabSheet eingefügt...Selber Fehler wenn es aktiv beim Start war.
Hoffe ihr habt Ideen
DarkPhenix
PS:
Wieso funktioniert das DoubleBuffering in Delphi 2009 nicht mehr? Musste mit Delphi 7 weiter programmieren, da beim FormResize ein Bild mit die Größe wechselt und es unheimlich geflackert hat. Als ich es in Delphi 7 probiert habe, funktioniert das ohne Flimmern (wenn DoubleBufferd=true). Wieso?
|
|
jaenicke
 
Beiträge: 19346
Erhaltene Danke: 1754
W11 x64 (Chrome, Edge)
Delphi 12 Pro, C# (VS 2022), JS/HTML, Java (NB), PHP, Lazarus
|
Verfasst: Fr 06.02.09 15:27
Der Fehler hört sich sehr danach an als hättest du irgendwo ein Speicherleck o.ä., ich vermute du benutzt z.B. dynamische Arrays und schreibst über den Bereich des Arrays hinaus.
Solche Fehler äußern sich nämlich sehr oft über unerklärliche Fehler in visuellen Komponenten, wenn dabei deren Speicher überschrieben wurde.
Der Fehler kann dabei am anderen Ende des Projekts liegen und durch irgendwelche Änderungen an anderer Stelle scheinbar behoben werden. In Wirklichkeit bleibt er dadurch nur länger unentdeckt.
www.delphi-forum.de/....php?p=527022#527022
Schalte einmal die Bereichsüberprüfung an und schau ob es da irgendwo einen Fehler gibt.
Projekt --> Optionen... --> Compiler --> Laufzeitfehler --> Bereichsüberprüfung
|
|
DarkPhenix 
Hält's aus hier
Beiträge: 10
WIN XP, WIN Vista
Delphi 7, Delphi 2009, JBuilder 2008, Visual Studio 2008, C++ Builder 2009
|
Verfasst: Fr 06.02.09 15:54
Also ich hab den geposteten Link nur kurz überflogen und einfach ausprobiert, was ich mir nach dem Beitrag etwa gedacht habe. Und zwar arbeite ich mit ner StatusBar und ner TGauge.
Als ich die Statusbar jetzt einfach mal weggelassen habe, kam der Fehler nicht mehr... Wo jetzt aber der Fehler liegt weiß ich aber immer noch nicht genau. Wenigstens konnte ich es schon einschränken. Jemand weitere Ideen?
| Zitat: |
Schalte einmal die Bereichsüberprüfung an und schau ob es da irgendwo einen Fehler gibt.
Projekt --> Optionen... --> Compiler --> Laufzeitfehler --> Bereichsüberprüfung
|
Das hab ich gemacht, aber da war keinerlei unterschied. Was sollte das denn bewirken?
|
|
jaenicke
Beiträge: 19346
Erhaltene Danke: 1754
W11 x64 (Chrome, Edge)
Delphi 12 Pro, C# (VS 2022), JS/HTML, Java (NB), PHP, Lazarus
|
Verfasst: Fr 06.02.09 16:05
 DarkPhenix hat folgendes geschrieben  : | | Zitat: |
Schalte einmal die Bereichsüberprüfung an und schau ob es da irgendwo einen Fehler gibt.
Projekt --> Optionen... --> Compiler --> Laufzeitfehler --> Bereichsüberprüfung
|
Das hab ich gemacht, aber da war keinerlei unterschied. Was sollte das denn bewirken? |
In vielen Fällen deckt das auf, wenn irgendwo an einer falschen Stelle in ein dynamisches Array geschrieben wird. Dafür wird beim Kompilieren Prüfcode hinzugefügt, der bei jedem Zugriff überprüft ob der Index gültig ist. Leider ist diese Überprüfung fehlerhaft, d.h. der Prüfcode wird leider nicht immer generiert.
Dass das entfernen der Statusbar den Fehler scheinbar beseitigt hat, bestärkt mich nur in dem Verdacht. Wenn dynamische Arrays nicht das Problem sind, dann könnten falsche Pointerspielereien, fehlende Freigaben von erzeugten Objekten, etc. die Ursache sein. Das kann ich so allgemein nicht sagen.
Ich weiß ja nicht wie groß das Projekt ist, ob du es einfach anhängen könntest?
|
|
DarkPhenix
Hält's aus hier
Beiträge: 10
WIN XP, WIN Vista
Delphi 7, Delphi 2009, JBuilder 2008, Visual Studio 2008, C++ Builder 2009
|
Verfasst: Fr 06.02.09 16:12
Also ich hab die Stelle gefunden per ausprobieren:
  Delphi-Quelltext
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
| procedure TForm1.FormShow(Sender: TObject);
var r:TRect;
begin
StatusBarDzuB.Perform(SB_GETRECT, 6, integer(@R));
GStatus.Parent := StatusBarDzuB;
GStatus.BoundsRect := r;
GStatus.Visible:=true; end;
procedure TForm1.FormResize(Sender: TObject);
var r:TRect;
begin
StatusBarDzuB.Perform(SB_GETRECT, 6, integer(@R));
GStatus.BoundsRect := r;
end; |
Mein TGauge ist anfangs nicht sichtbar, daher muss ich es sichtbar machen. Wenn ich die Zeile weglasse und das TGauge unsichtbar bleibt funktioniert alles, lass ich die Zeile weg und stell GStatus generell auf sichtbar kommt der Fehler weiterhin... Jedoch kommt er nicht beim FormShow, sondern nur wenn ich vom 2ten Tab in den ersten will... StatusBarDzuB ist die Statusbar des ersten Tabs.
|
|
jaenicke
Beiträge: 19346
Erhaltene Danke: 1754
W11 x64 (Chrome, Edge)
Delphi 12 Pro, C# (VS 2022), JS/HTML, Java (NB), PHP, Lazarus
|
Verfasst: Fr 06.02.09 16:18
Ich glaube eher, dass auch das ein zufälliger Effekt ist. Wie ich sagte: Durch Änderungen an ganz anderer Stelle behebt man solche Fehler scheinbar. Aber eben nicht wirklich.
Du könntest auch einmal mit FastMM nach Speicherlecks suchen:
sourceforge.net/projects/fastmm/
Wie das genau geht, dazu sagt vielleicht z.B. BenBE noch etwas, wenn er das liest. Und ich nehme an ihm fällt auch noch mehr zu dem Thema ein. 
|
|
|
