![]() |
StyleManger verursacht Stack Overflow
Hallo,
keine Ahnung was ich an meinem Programm verbockt habe. Wenn ich beim Starten des Programmes einen neuen Style anwende z.B. TStyleManager.TrySetStyle('Sky') dann funktioniert das wunderbar. Rufe ich den StyleManger während der Laufzeit nocheinmal auf, um einen andren Style zu setzen, bekomme ich einen Stackoverflow in system.pas in _CallDynaInst. Ich weiß, dass das Ganze schon einmal funktioniert hat, ich habe nur keine Ahnung was ich seitdem geändert habe, das so ein Verhalten provozieren könnte. Der Rest der Applikation läuft unauffällig einzig dieser Funktionsaufruf scheitert. Ein Aufruf mit demselben Style wie bein Create klappt. Wenn ich den anderen Style direkt beim Create einstelle klappt das auch, nur ein Wechsel verursacht dann einen Stack Overflow.:?: Vielleicht hat ja von euch jemand eine Idee, wo ich zum Suchen anfangen kann. |
AW: StyleManger verursacht Stack Overflow
Das hat nicht zufällig was mit der in
![]() |
AW: StyleManger verursacht Stack Overflow
Hallo,
ja das war auch mein erster Verdacht, aber nach einem 'Rückbau' der Änderungen, bleibt das Fehlerbild erhalten. Was ich noch viel bemerkenswerter finde - wenn ich in Create die Funktion nacheinander mit verschiedenen Styles aufrufe passiert nichts. Aber sobald ich den Aufruf aus dem laufenden Programm mache kracht es. Also habe ich testweise den kompletten Code in Create rauskommentiert um auszuschliessen, dass da etwas schief läuft - gleiches Bild. |
AW: StyleManger verursacht Stack Overflow
Im Create ist die Form noch unsichtbar.
Später sichtbar. Also entweder liegt es an einer Komponente, die bereits gezeichnet wurde und nun da etwas schief steht, oder es liegt an einem Ereignis, worauf nur sichtbare Komponenten reagieren. (also im Create hätte es auch geknallt, wäre die Form bereits sichtbar gewesen) |
AW: StyleManger verursacht Stack Overflow
Zitat:
Oder gibt es eine Routine, wo ich mir sinnvoll einen Breakpoint setzen kann, um zu sehen, welche Komponenten gerade aktuallisiert werden? |
AW: StyleManger verursacht Stack Overflow
Nja, blöd ist ja, dass der Stacktrace vorzeitig abbricht (ein Limit) und man bei einem Stacküberlauf dann nur sieht wo es in der Schleife läuft, aber da wo die Schleife anfing, das bleibt im Dunklen.
Dass es einen Bruch gibt, ist ja OK, aber hier wäre es nett, wenn Emba uns dennoch einen "Alles laden"-Knopf geben würde. (oder wenn man in der Mitte nach x Einträgen alles weg läßt und dann den Anfang auch noch anzeigt) Man könnte den zwar den Stackspeicher verrigern ... so klein, damit der Abbruch früher kommt und der Stack noch bis zum Anfang ausgelesen wird .... aber neeeee. Nja, du siehst ja wo es in der Schleife fest hängt ... da macht man an einen der wiederholenden Stellen einen Haltepunkt. In CPU-Ansicht oder besser im Code, wenn es das gibt, weil die DLL ja beim nächsten Start wo anders liegen könnte. Dann neu starten, hoffen, die gewählte Stelle erst beim Überlauf durchlaufen wird. Ergebnis man ist am Anfang des Überlaufs und sieht daher noch was vorher im Stack steht, also wer für den Überlauf verantworklich ist. |
AW: StyleManger verursacht Stack Overflow
Hallo,
kurze Rückmeldung zu meinem Problem: ich hatte das Thema für mich erst mal beerdigt, weil ich bei der Ursachensuche nicht voran gekommen war. Da der Wechsel des Styles 'nur' dann Probleme verursacht hat, wenn das während des Programlaufs versucht wurde, habe ich das einfach in die Startphase (Create) verlegt. Man muss halt dann nach der Auswahl immer einen Neustart des Programms machen, nicht schön funktioniert. Vorhin habe ich aus einer Laune heraus das Thema noch einmal angeschaut und dabei festgestellt, dass in VCL.Forms CreateParams die Zuweisung WndParent := Application.MainFormHandle in Folge wieder CreateParams aufruft. Passiert aber anscheinend nur, wenn der PopupMode des Hauptfensters auf pmExplicit gesetzt ist. Das hatte ich wohl beim Testen von Lösungen für mein anderes Problem (Hauptformular blieb durch andere Formulare verdeckt, obwohl es ausgewählt war) auf pmExplicit gestellt - zurück auf pmNone gestellt und alles ist OK. Habe das Ganze auch mal in einem Testprojekt probiert: Formular, dass einen Button enthält, der dann StyleManager.TrySetStyle('Sky') aufruft - sobald im (Haupt)Formular pmExplicit gesetzt ist, bekomme man einen Stack Overflow. |
AW: StyleManger verursacht Stack Overflow
Zitat:
|
AW: StyleManger verursacht Stack Overflow
Ich habe es einmal kurz ausprobiert. Der Stacktrace wird bei mir komplett angezeigt.
Das Problem ist sehr einfach erklärt: Es wird im Zuge des Änderns des Styles ein CM_RECREATEWND geschickt. Das sorgt dafür, dass das Fensterhandle neu erzeugt wird. Nun ist es dummerweise so, dass TCustomForm.CreateParams so aussieht:
Delphi-Quellcode:
Sprich, wenn der PopupMode auf pmExplicit steht, wird dort auf Application.MainFormHandle zurückgegriffen. Das existiert ja gerade nicht, also wird dort wiederum ein neues Handle erzeugt, aber dummerweise gibt es das nicht, also wird ein neues Handle erzeugt, aber dummerweise... ihr versteht.
pmExplicit:
begin if Assigned(FPopupParent) and not (csDesigning in ComponentState) then begin WndParent := FPopupParent.Handle; LParent := FPopupParent; end else WndParent := Application.MainFormHandle; Da ja offenbar immer noch kein Bugreport vorhanden ist (ich konnte auch keinen finden, habe z.B. nach pmExplicit gesucht), habe ich das nun erledigt: ![]() |
Alle Zeitangaben in WEZ +1. Es ist jetzt 21:41 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz