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.

OK, dachte das war beim SetFocus auch so,
aber nur beim Show wird umgelättert.

Edit2 auf nicht sichtbarem TabSheet

zusammenfalten · markieren

Delphi-Quellcode:

procedure TForm2.Button1Click(Sender: TObject);
begin
  Edit2.Show;
  Edit2.SetFocus;
end;

// oder
begin
  Edit2.Show; // übergeordnete PageControls umblättern, falls nötig
  if Edit2.CanFocus then
    Edit2.SetFocus
  else
    GetParentForm(Edit2).ActiveControl := Edit2;
end;

Guten Morgen.

Leider betrifft es mich nicht in diesem Fall. Es könnte aber etwas mit einer Scrollbox zu tun haben, welche ich bei einer Datenbankoperation auf disabled stellte.

Als ich die ScrollBox nicht sperrte, landete ich gestern bei einem kurzen Test nicht mehr im CPU-Register. Innerhalb dieser ScrollBox greife ich auf Comboboxen zu, aber nur lesend, ohne SetFocus. Ich bin immer noch auf der Suche..

Bis später.

LG Mathias

Schau mal, ob das Problem etwas mit dem gelöschten fokussierten Control zu tun haben kann.

Ich hatte früher mal bei eigenen Controls das Problem, dass Windows noch ein Control ohne Focus neu zeichnen wollte, das ich aber zwischenzeitlich dynamisch gelöscht hatte.
Evtl. reicht es, wenn Du den Focus vor dem Löschen auf das Formular oder ein anderes Control setzt, welches nicht mit freigegeben wird.

Oder Du kannst das Control auch zunächst unsichtbar schalten bis Windows dessen Sichtbarkeits-Status erkannt hat. Danach kannst Du es dann löschen, ohne dass Windows durcheinander kommt.

Also nicht:

- fokussiertes Control löschen

sondern:

- fokussiertes Control unsichtbar schalten
- dieses Control merken
- und später (z.B. in einem Timer) das gemerkte Control löschen

Mit diesem Workaround konnte ich mal so ein Problem lösen.

Ideal wäre es ja, wenn Delphi in den SetFocus-Exceptions den Namen des Controls anzeigen würde, aber das tun die leider nicht. (und es gibt unmassen von Stellen, welche sich alle nicht ändern lassen. (fast nirgendwo ein virtual)