StyleManger verursacht Stack Overflow

[RayEn]

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.

[Uwe Raabe]

Das hat nicht zufällig was mit der in deinem anderen Thread geschilderten Problem bzw. dessen Lösung zu tun?

[RayEn]

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.

[himitsu]

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)

[RayEn]

Zitat von himitsu:

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)

Ja klingt logisch - da der Überlauf anscheinend erst beim updaten auftritt - die Funktion TrySetStyle selbst wird ohne Fehler beendet - muss ich wohl mal sukzessive Elemente entfernen um den Übeltäter zu finden.
Oder gibt es eine Routine, wo ich mir sinnvoll einen Breakpoint setzen kann, um zu sehen, welche Komponenten gerade aktuallisiert werden?

[himitsu]

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.

[RayEn]

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.

[Uwe Raabe]

Zitat von RayEn:

Formular, dass einen Button enthält, der dann StyleManager.TrySetStyle('Sky') aufruft - sobald im (Haupt)Formular pmExplicit gesetzt ist, bekomme man einen Stack Overflow.

Hört sich nach einer guten Vorlage für einen Bugreport an.

[jaenicke]

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:

          pmExplicit:
            begin
              if Assigned(FPopupParent) and not (csDesigning in ComponentState) then
              begin
                WndParent := FPopupParent.Handle;
                LParent := FPopupParent;
              end
              else
                WndParent := Application.MainFormHandle;

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.

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:
https://quality.embarcadero.com/browse/RSP-39019