Fehler vor OnCreate finden

[Ykcim]

Die Option goEditing ist deaktiviert. Ich arbeite bei dem Grid mit der Procedure CanEditCell:

Delphi-Quellcode:

procedure TFrame_Listendruck.Grid_not_printedCanEditCell(Sender: TObject; ARow,
  ACol: Integer; var CanEdit: Boolean);
begin
   CanEdit:=(ACol in [15,16]);
   if (Sender as TAdvStringGrid).Cells[19,ARow]<>'' then begin
      CanEdit:=(ACol in [7,8,13,14,15,16,18]);
   end;
   if ARow=1 then
      CanEdit:=(ARow in [1]);
end;

Warum das zu diesem Zeitpunkt irgendwie Ärger macht wüßte ich nicht und vor allem, warum nur auf diesen beiden Rechnern...

LG Patrick

[Delphi.Narium]

Hast Du eine MAP-Datei?

Findest Du in ihr die Fehleradresse?

Wenn ja, sollte das in etwa so aussehen:

Code:

Line numbers for NameDerFehlerhaftenUnit(NameDerFehlerhaftenUnit.pas) segment .text

    47 0001:00295DC8    48 0001:00295DEA    49 0001:00295DF7    50 0001:00295DFC
    51 0001:00295E05    52 0001:00295E1F    54 0001:00295E2D    55 0001:00295E39
    57 0001:00295E3C    58 0001:00295E53    60 0001:00534460    61 0001:00534480

Jede Zeile besteht aus vier Blöcken. Jeder Block aus der Zeilennummer des Quelltextes, die zu dieser Fehleradresse gehört, 0001:Fehleradresse.

In diesem Beispiel wäre der Fehler in der Unit NameDerFehlerhaftenUnit.pas in Zeile 60 zu finden.

Dahin gehen, Breakpoint (ggfls. ein paar Zeilen davor) setzen und dann schrittweise durchsteppen.

Findest Du die exakte Fehleradresse nicht, so suche nach einem Wert, der etwas kleiner ist. Also statt nach :00534460 z. B. nach :005344. Gehe zur entsprechenden Stelle im Quelltext und steppe ab dort schrittweise durch.

Sherlock hat drauf hingewiesen, dass der Fehler "irgendwo im Umfeld von TAdvStringGrid.Click" zu suchen ist, hoika hat das präzisiert.

In welcher / welchen Units nutzt Du das TAdvStringGrid?
Eine dieser Units wird den Fehler (vermutlich) enthalten.
Wird dort irgendwo programmatisch ein OnClick-Ereignis dieser Komponenten ausgelöst?
Oder wird eine Routine aufgerufen, die eine programmatische Änderung des TAdvStringGrid auslösen könnte. Wenn ja, kommentiere diese Routinen aus und prüfe, ob der Fehler bestehen bleibt. Wenn nein, aktiviere die entsprechenden Stellen im Quelltext wieder, aber immer nur eine, damit Du feststellen kannst, welche konkret den Fehler verursacht.

Wenn der Fehler mit CanEditCell zusammenhängt, kann das ein Timingproblem sein. Irgendwas ist bei diesen beiden Rechnern noch nicht da, was bei den anderen Rechner zum Zeitpunkt des Aufrufes dieser Routine schon vorhanden ist.

Im Screenshot ist nicht wirklich viel "sinnvolles" zu sehen, aber: Scrolle soweit vor oder zurück, bis Du eine Info findest, mit der Du was anfangen kannst. Notfalls per Einzelschritt durchsteppen, bis Du an eine für Dich "verständliche" Stelle kommst. In dem Fall liegt der Fehler dann "irgendwo davor".

Das der Fehler nur auf diesen beiden Rechnern entsteht, hängt damit zusammen, dass sie (vermutlich) sehr ähnlich sind, sowohl in Bezug auf Hard- als auch auf Software. Eventuell sind sie aus irgendeinem Grund etwas schneller oder etwas langsamer oder laden andere Treiber ... Sie stolpern über einen versteckten Fehler, der auf den anderen Systemen (ggfls. bei nur marginaler Änderung von was auch immer) ebenfalls auftreten kann. So ein bisschen sowas wie 'ne Zeitbombe.

[Sherlock]

Und es gibt keine Ereignisbehandlung für das Click in diesem Grid?
 Frame_ListendruckUnit 284 +1 TFrame_Listendruck.Grid_not_printedClick
Sherlock

[hoika]

Hallo,
verlagere das Füllen des Grids ins FormActivate.

Zusätzlich könntest du dein Grid-Event etwas absichern:

Delphi-Quellcode:

Formularvariable
  bAfterFormActivate: Boolean;

procedure TForm1.FormCreate;
begin
  bAfterFormActivate:= False;  // müsste eigentlich schon False sein
end;


procedure TForm1.FormActivate;
begin


  // ganz unten
  bAfterFormActivate:= True;
end;

procedure TForm1.Grid_not_printedCanEditCell()
begin
  if not bAfterFomActivate then
  begin
    CanEdit:= False;
    Exit;
  end;
end;

[hoika]

Hallo,

Zitat:

Und es gibt keine Ereignisbehandlung für das Click in diesem Grid?

Das Problem ist, dass die OnClick wahrscheinlich beim Füllen des Grids im FormCreate vom Grid selbst aufgerufen wird,
siehe CallStack Seite 1.

[hoika]

Hallo,

Zitat:

Im Screenshot ist nicht wirklich viel "sinnvolles" zu sehen

Doch
Man muss den Callstack ja von unten nach oben lesen.

007e1f0e +1b3a NedCom.exe AdvGrid 41726 +667 TAdvStringGrid.WMLButtonUp
00454ef5 +0025 NedCom.exe System.SysUtils StrLCopy
005c0e57 +0057 NedCom.exe Vcl.Themes TUxThemeStyle.DoDrawText

Genauer das WMLButtonUp ist schon sehr komisch.
Das wird ja nicht vom Anwender erzeugt, sondern intern vom Grid in der WndProc.


Was ich auch schon mal hatte im Zusammenhang mit TMS und Laptop mit Touchscreen:
in Form1 Doppelklick auf ein Grid, Form2 öffnet sich, ein Mausklick von Form1 wurde an Form2 "durchgereicht".

[Ykcim]

Hallo Zusammen,

vielen Dank für Eure Hilfe! Ich versuche nachfolgende zu antworten:

Zitat:

Nutzt Du die JEDIs? Dann nimm dort den TJvDebugHandler, der hilft Dir an Fehlerursachen zu gelangen.

Nein, benutze ich nicht.

Zitat:

Und es gibt keine Ereignisbehandlung für das Click in diesem Grid?
Frame_ListendruckUnit 284 +1 TFrame_Listendruck.Grid_not_printedClick
Sherlock

Es gibt ein OnClick-Event. Zu Testzwecken habe ich den Inhalt vollständig auskommentiert, damit wenn das Event aufgerufen wird nichts gemacht wird, aber das hatte keine Auswirkung...

Zitat:

verlagere das Füllen des Grids ins FormActivate

Das Grid wird zu diesem Zeitpunkt nicht gefüllt. Damit Daten in das Grid kommen, muss der User erst eine Auswahl treffen.

Zitat:

Das der Fehler nur auf diesen beiden Rechnern entsteht, hängt damit zusammen, dass sie (vermutlich) sehr ähnlich sind, sowohl in Bezug auf Hard- als auch auf Software. Eventuell sind sie aus irgendeinem Grund etwas schneller oder etwas langsamer oder laden andere Treiber ... Sie stolpern über einen versteckten Fehler, der auf den anderen Systemen (ggfls. bei nur marginaler Änderung von was auch immer) ebenfalls auftreten kann. So ein bisschen sowas wie 'ne Zeitbombe.

Die Rechner sind sehr ähnlich von der Hardware her, aber auf dem einen habe ich Windows10 aufspielen lassen, weil ich dachte, dass das BS einen Schuss hatte und das andere hat Windows7 als BS. Beide BS sind auch auf anderen Rechnern, die ohne Probleme laufen. Ob es an der Hardware liegt, weiß ich nicht.
Zeitbombe: Das sehe ich auch so, deshalb beschäftige ich mich damit, obwohl es noch kein Ausfall auf einer Produktivmaschine gibt.

Zitat:

Hast Du eine MAP-Datei?

Ja, habe ich. Sie hat 237.000 Zeilen...

Zitat:

Findest Du in ihr die Fehleradresse?

Im BugReport steht Folgendes: Zugriffsverletzung bei Adresse 005345D4 in Modul 'NedCom.exe'. Lesen von Adresse 00000260.
Die 005345D4 finde ich nicht, aber die 00000260:

Zitat:

0001:004974EC 00000260 C=CODE S=.text G=(none) M=AdvDWM ACBP=A9
0001:009BBE50 00000260 C=CODE S=.text G=(none) M=_UXlsBaseRecords.TDefaultRowHeightRecord ACBP=A9
0001:00B3E8E8 00000260 C=CODE S=.text G=(none) M=_UOle2Properties.TPropIdOffset ACBP=A9

Aber leider weiß ich nicht, wie mir das weiterhelfen kann...

Zitat:

Was ich auch schon mal hatte im Zusammenhang mit TMS und Laptop mit Touchscreen:
in Form1 Doppelklick auf ein Grid, Form2 öffnet sich, ein Mausklick von Form1 wurde an Form2 "durchgereicht".

Beide Rechner sind Laptops ohne TouchScreen

Zitat:

Genauer das WMLButtonUp ist schon sehr komisch.
Das wird ja nicht vom Anwender erzeugt, sondern intern vom Grid in der WndProc.

Das ist meine Sorge, dass es in einem Teil passiert, auf den ich keinen Einfluss habe...

Hat jemand vielleicht ein Idee, warum das mit dem Remote-Debugger nicht klappt? Vielleicht würde ich ja so der Ursache auf die Spur kommen...

Vielen Dank für Eure Mühe - diese Art der Fehlersuche ist für mich Neuland!

LG Patrick

[jaenicke]

Zitat von hoika:

Das Problem ist, dass die OnClick wahrscheinlich beim Füllen des Grids im FormCreate vom Grid selbst aufgerufen wird,
siehe CallStack Seite 1.

Wo steht da etwas von FormCreate? Das ist ein normaler Mausklick, durch den das Editieren einer Zelle ausgeführt wird. Welches Control da den Fokus bekommen soll, lässt sich ohne des Grid-Quelltext nicht sagen, aber das kann ja eigentlich nur der eingestellte Zelleneditor oder das Grid selbst sein.

Der Fehler hat aber nichts mit dem beschriebenen Crash beim Start zu tun.

Zitat von Ykcim:

Zitat:

Findest Du in ihr die Fehleradresse?

Im BugReport steht Folgendes: Zugriffsverletzung bei Adresse 005345D4 in Modul 'NedCom.exe'. Lesen von Adresse 00000260.
Die 005345D4 finde ich nicht, aber die 00000260:

Zeig doch einmal diesen Bugreport. Der erste Teil mit dem ersten Stacktrace inklusive reicht schon.

Adresse 005345D4 ist die Stelle im Code, an der der Fehler auftritt. Die muss nicht exakt in der Mapdatei stehen, denn der Fehler muss ja nicht direkt mit dem Start der Methode auftreten. Die 260 bedeutet wahrscheinlich, dass auf eine Property eines nicht initialisierten Objekts zugegriffen wird, die 260 Byte nach dem Beginn der Klassendefinition kommt. Mehr sollte der Stacktrace verraten.

[freimatz]

Zitat von hoika:

007e1f0e +1b3a NedCom.exe AdvGrid 41726 +667 TAdvStringGrid.WMLButtonUp
00454ef5 +0025 NedCom.exe System.SysUtils StrLCopy
005c0e57 +0057 NedCom.exe Vcl.Themes TUxThemeStyle.DoDrawText

Nur so als Idee, könnte es sein, dass StrLCopy Speicher überschreibt?
Dann kam mir beim googeln nach "TUxThemeStyle.DoDrawText" das da: https://stackoverflow.com/questions/...-of-the-screen

[Ykcim]

Hier der BugReport - etwas gekürzt um doppelte Einträge