Debugger hält bei breakpoint, aber ist verdeckt von Forms

[mcmichael]

Bei meinem Projekt hält der Debugger wie gewünscht an, aber die IDE bleibt durch die drei Forms des Programms verdeckt.

Bei einem neuen Projekt ist das Verhalten anders. Ich habe den Verdacht, dass es an irgendeiner Eigenschaft der Forms
liegt - aber welche?

Die folgenden hatte ich im Verdacht, aber die ändern das Verhalten nicht.
Borderstyle=bsNone
FormStyle=fsNormal
WindowState=wsNormal

hat jemand eine Idee?

Ich nutze Delphi XE3 unter Windows7

[Bernhard Geyer]

Evtl. durch Application.MainFormOnTaskBar beeinflusst?

[mcmichael]

nein. Die Eigenschaft habe ich nicht angerührt.

[TiGü]

Zitat:

Zitat von mcmichael (Beitrag 1276507)

Borderstyle=bsNone
FormStyle=fsNormal
WindowState=wsNormal

Bei alten Code wurde diese Zuweisung gerne auch mal ins FormCreate geschrieben.
Oder es wurde per Windows-Funktionen, wie bspw. SetWindowPos, das Verhalten verändert.

[himitsu]

Nein, es kann auch einfach so passieren.

Solchen Code haben wir rausgeworfen und beim Debuggen hält der Debugger oder die VCL die Fenster oben.

Ich hatte in XE sogar schon 5-6 Mal den Fall, daß das Programm vorne blieb und kein anderes Programm in den vordergrund kommen konnte.
Weder durch Alt+Tab, noch durch Anklicken der Buttons in der Taskleiste ... dort blinkten die Buttons sogar nur noch orange, aber sonst passierte nichts.

Nur Strg+Esc (Task-Manager) sind vorgekommen und ich mußte Delphi abschießen. Das Programm läßt sich nicht abschießen, solange der Debugger am Haltepunkt wartet.

[mcmichael]

genau das! Kein Programm schafft's in den Vordergrund und die Fenster des debuggten Programmes lassen sich nicht mehr verschieben...

Wie hab ich das hinbekommen, bzw. wie krieg ich's wieder weg...?

[Stevie]

Eventuell irgendwo mit nem HWND_TOPMOST rumgepfuscht?

[himitsu]

Nein.
Bei mir war es das Debuggen des Erstellens/Anzeigens der Form, wo sich eine fiese Exception versteckt, die ich finden wollte, aber nach deren Auslösung der Debugger nicht verwertbares mehr anzeigt.

Meine Lösung war einfach.
2 Monitore, wo das Programm nicht vorm Debugger rumhängt. :angel:

Meistens aber nur hilfreich, wenn man vorher weiß, daß es gleich hängen wird, oder man immer ganz eisern dafür sorgt, daß Debugger und Programm sich nie verdecken, bzw. man immer die Möglichkeit hat den Debugger noch anzufassen und rauszuziehen.

[Stevie]

Windows-Taste und Pfeiltaste links/rechts und schon ist deine IDE aufm anderen Screen :)

[mcmichael]

ohne zweiten Monitor an dem System ist das aber sehr lästig...

Das ist doch ein ziemlich fetter Bug in Delphi, oder wie muß ich das sehen?
Schließlich kann ich bei - nicht vorher bestimmbaren - Bedingungen mein Programm
nicht mehr debuggen.

Sollte Embarcadero da nich mal aktiv werden? Oder sieht sich die Firma da außerhalb
ihrer Verantwortung?

[himitsu]

Nunja, man kann sich bestimmt via OTA reinhacken und verpasst den IDE-Forms ein StayOnTop, dann wäre die IDE immer vorne, was aber auch wieder blöde ist, da dann auch das laufende Programm dahinter wäre.
Da müsste man dann auch noch aktivieren, daß sich die IDE minimiert. (mindestens beim Starten des Debuggens und bei F9, aber besser nicht bei F7 usw., denn dann würde man voll kirre, wenn die im Milisekundentakt auf und zu geht)

[Der schöne Günther]

Ich habe bei mir auch keine andere Lösung gesehen als im Programm selbst die Überprüfung einzubauen, ob die Anwendung grade debugged wird. Wenn ja, dann kein

Delphi-Quellcode:

fsStayOnTop

.

Aber wenn du sagst, du hast überhaupt kein "Stay On Top" drin...

[himitsu]

Wir haben bei uns alle StayOnTop entfernt, da es damit eh nur Probleme gibt. (die Ausrichtung innerhalb des Programms wird nun über PopupMode/PopupParent geregelt)

Aber dennoch gibt es manchmal dieses Problem.
Multimonitor oder im SplitScreen (Debugger eine Seite und das Programm die andere Bildschirmhälfte) arbeiten ist die einzige wirklich brauchbare Lösung.

[mcmichael]

fsStayOnTop habe ich auch überall entfernt. Und ich bin notgedrungen auf's debuggen über ein logging an den fraglichen Programmstellen übergegangen. Damit kann ich aber die ganzen Möglichkeiten der IDE beim Debuggen nicht nutzen. Ich werde jetzt mal Schritt-für-Schritt das Programm neu aufbauen (insbesondere die Forms) und nachschauen wann der "Ausfall" kommt.
Oder hat das irgendjemand schon herausgefunden? Denn beim leeren Programm oder "MinimalProgrammen" (=1Form, 3 Buttons...) läuft alles prima.

[himitsu]

Das lernt man eh mit der Zeit.
> In einer einfachen Testanwendung geht es fast immer und in einer großen Anwendung geht der selbe Code plötzlich nicht mehr.

Bei mehreren Fenstern und/oder mit sichtbaren Dialogen, bzw. ShowModal (am Schlimmsten sind solche, wie von Eurekalog, welche sich garnicht an Standards halten) gibt es gerne mal Probleme, da dort gern mal an der Fensterausrichtung (Z-Achse) rumgepfuscht wird und das nicht nur am eigenen Fenstern, sondern auch an den anderen Fenstern der Anwendung. Manchmal auch mit bösen Hooks. (z.B. Eurekalog und AQTime arbeiten auch gern mit Threads und zerschießen/unterbrechen auch schonmal den Stacktrace, da sie eigenen Code reinhaken)

[mcmichael]

Das Vorhaben ist gelungen:

Ich habe ein neues VCL-Projekt eröffnet.
Habe die Forms mit gleichen Namen hinzugefügt und gespeichert.
Habe die form-losen Units in das Verzeichnis kopiert
habe die "nicht-Form-Attributes" aus den alten *.dfm Dateien in die aktuellen *.dfm Dateien kopiert
habe den Code aus den alten Form-Units in die neuen kopiert.

Läuft. Mit Öffnen der IDE bei breakpoints.
Habe keine Ahnung warum. Irgend eine Eigenschaft oder Projekt-Einstellung hat's vorher verhindert.
:)