Huhu.

Irgendwo in meinem Programm habe ich scheinbar einen .SetFocus gesetzt und lande nun immer im CPU-Register, anstatt beim entsprechenden Code in der IDE.

Nun ist es leider zu mühsam alle Breakpoints auf .SetFocus zu setzen, um zu schauen, wann der richtige angesprungen wird.

Wie kann ich denn nun aber Rückschlüsse von der CPU-Ansicht auf den entsprechenden Code ableiten?


Edit: Habe dann doch während der Laufzeit alle Breakpoints gesetzt. Es wurde kein .SetFocus angesteuert.

Das Problem hat sich etwas verlagert, es ist scheinbar ein Tabellenproblem. Imemr wenn ich bei einer geöffneten Tabelle diese mittels .Append vorbereite, um neue Daten zur Tabelle hinzuzufügen, tritt genau dann das Fokusproblem auf (siehe Screenshot). Die Frage bezüglich CPU-Ansicht bleibt aber gleich.



LG Mathias

Wenn du im CPU Fenster landest, ist die exception in einer Unit, von der nur die vorkompilierte DCU ohne Debuginfos vorhanden ist. Das müsste also wahrscheinlich in irgend einer 3rd Party Komponente oder einer Delphi Komponente sein. Im 2. Fall reicht es eigentlich, wenn du beim Kompilieren die Debug dcu's der IDE nutzt. Dazu musst du in den Debugsettings deines Programms, die Option "Debug DCUS's nutzen" aktivieren.

Wenn die Exception auftritt, kannst du dir auch mal den Stack anschauen, wo der letzte Codeteil ist, der über Debuginfos verfügt.

In den Stacktrace schauen, ob es vorher irgendwo etwas gibt, wozu es eine Unit (Modul mit Debuginfos) gibt.

Eventuell auch noch ein/zwei Mal F7 drücken ... manchmal kommt man so auch z.B. zu einem übergeordneten Try-Except zurück, mit dem man was anfangen kann.

So eine Exception hatte ich letztens auch mal. Ursache war, dass ich im FormShow-Handler einer gelegentlich genutzten Form einem Edit-Control den Focus gab, welches auf einem PageControl1.TabSheet1 saß. Der Haken daran, kurz vorm letzten Closen dieser Form, hatte ich ab und zu auf PageControl.TabSheet2 noch letzte Eingaben gemacht, welches damit dann also das zuletzt angezeigte TabSheet war. Folge: Als ich die Form erneut anzeigen ließ, war in dem Fall dieses TabSheet2 also immer noch das sichtbare, und das Edit-Control auf TabSheet1 damit natürlich nicht sichtbar.

Das ist eine der Exceptions, für die sicherlich reichlich solche oder ganz ähnliche Gründe vorstellbar sind.

Fokus in einem ausgeblendeten Tab eines PageControls ist kein Problem, denn dort wird automatisch die Seite umgeblätert.

PS: Man kann in der Form ActiveControl setzen, wenn man den Fokus vor/außerhalb der Sichtbarkeit der Form zuweisen möchte.
(bei eingebetteten Forms ist das Auslesen jeweils bei der obersten Form möglich)

Die globale Screen-Variable, da sind zwei Events drin, wo man auf Fokusänderungen reagieren kann, und da könnte man auch einen Haltepunkt reinmachen.
Wenn der Fokus aber via PostMessage geändert wurde, dann bekommt man bei Änderungen nicht mit, wer es war (Stacktrace) ... dann kann man nur noch die zuvielen SetFocus und Co. debuggen.

In meinem Prog bleibt das zuletzt aktiv gewesene TabSheet aber dasjenige, welches auch nach einem neuen Anzeigen der Form immer noch sichtbar ist. Habe das gerade nochmal gecheckt. Da gibts kein automatisches Umblättern. Oder ich müsste sowas (wenn's selbst wieder eine Property ist) ausgeschaltet haben, oder erst garnicht angeschaltet, weil es sich um ein minimal älteres Prog handelt? Erst wenn ich ins FormShow() eine < Ln1PageControl.ActivePage := BlablaTabSheet1; > -Anweisung einfüge, und damit sicherstelle, dass bei jedem neuen FormShow auch dieses TabSheet1 sichtbar ist, gibt's keine Exception mehr.