| Autor |
Beitrag |
DelphiNoob
      
Beiträge: 152
Win 2003 Server
D7 Ent
|
Verfasst: Mi 12.02.03 17:01
Hi,
bastel gerade an einem teil meines Programms, und es funzt auch alles super! Verbinde mit der ZEOS Komponente zu meiner Datenbank (mySQL), und rufe Daten ab, sie werden auch angezeigt! Echt alles super.
Nur wenn ich im Testmodus (diese Playtaste im IDE) das Programm laufen lasse, und danach irgendwann auf das X drücke zum beenden, dann kommt ein Fenster mit Debugger Exception ?!?!?!?
Ich kann damit wenig anfangen, weil wenn ich das Prog ohne IDE laufen lasse, also z.b. vom Explorer anklicke und beende ist es fehlerfrei?
Hier mal die genaue Fehlermeldung, vieleicht weiß ja jemand wie ich die weg bekomme!
| Zitat: | | Im Projekt alpha.exe ist eine Exception der Klasse EAccessViolation aufgetreten. Meldung: 'Zugriffsverletzung bei Adresse 0041D902 in Modul 'alpha.exe'. Lesen von Adresse 00000008'. Prozess wurde angehalten. Mit Einzelnen Anweisungen oder Start fortsetzen. |
Ich poste vorsichtshalber auch mal die Codezeilen, vieleicht findet ja wer einen ominösen Fehler?!
Quelltext 1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12: 13: 14: 15: 16: 17: 18: 19: 20: 21: 22: 23:
| procedure TForm1.DesktopDblClick(Sender: TObject); var progpfad: string; begin if reason = true then begin reason := false; qrMain.SQL.Text:=('select * from programme where programm = "'+clickprog+'"'); qrMain.Open;
progpfad := qrMain.FieldByName('pfad').AsString;
qrMain.Close; trMain.Disconnect; dbMain.Disconnect;
If progpfad = '' then MessageDlg('Unbekanntes Programm!',mtError,[mbOk],0) else //RunProcess(progpfad); MessageDlg(progpfad,mtInformation,[mbOk],0) end; end; |
Hab das RunProcess mal Auskommentiert, genauso wie die Funktion, um zu schauen ob es daran liegt. Ist nicht der fall!
Aber das Programm funzt ja auch, nur halt beim Beenden dieser Fehler?! Macht mir halt nen bissel Sorgen...
Mfg
DelphiNoob
|
|
Christian S.
      
Beiträge: 20451
Erhaltene Danke: 2264
Win 10
C# (VS 2019)
|
Verfasst: Mi 12.02.03 19:19
1. Sind solche Nachfragen sehr unhöflich. Da musst Du schon mal länger als anderthalb Stunden warten.
2. Bitte poste doch auch mal die Prozedur für das OnClose-Ereignis der Form und alle anderen Prozeduren, die beim Schließen des Programmes aufgerufen werden.
MfG,
Peter
P.S.: Und nochmal: nicht so ungeduldig sein.
_________________ Zwei Worte werden Dir im Leben viele Türen öffnen - "ziehen" und "drücken".
|
|
DelphiNoob 
      
Beiträge: 152
Win 2003 Server
D7 Ent
|
Verfasst: Mi 12.02.03 19:27
Sorry für die ungedult, brenne halt darauf weiter arbeiten zu können *g*
1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12: 13: 14: 15: 16: 17: 18: 19: 20: 21: 22: 23: 24: 25: 26: 27: 28: 29: 30: 31: 32: 33: 34: 35: 36: 37: 38: 39: 40: 41: 42: 43: 44: 45: 46: 47: 48: 49: 50: 51: 52: 53: 54: 55: 56: 57: 58: 59: 60: 61: 62: 63: 64: 65: 66: 67: 68: 69: 70: 71: 72: 73: 74: 75: 76: 77: 78: 79: 80: 81: 82: 83: 84: 85: 86: 87: 88: 89: 90: 91: 92: 93: 94: 95: 96: 97: 98: 99: 100: 101: 102: 103: 104: 105: 106: 107: 108: 109: 110: 111: 112: 113: 114: 115: 116: 117: 118: 119: 120: 121: 122: 123:
| function RunProcess(FileName: string): Longword; var StartupInfo: TStartupInfo; ProcessInfo: TProcessInformation; begin FillChar(StartupInfo, SizeOf(StartupInfo), #0); StartupInfo.cb := SizeOf(StartupInfo); StartupInfo.dwFlags := STARTF_USESHOWWINDOW or STARTF_FORCEONFEEDBACK; StartupInfo.wShowWindow := SW_SHOW; if not CreateProcess(nil, @Filename[1], nil, nil, False, CREATE_NEW_CONSOLE or NORMAL_PRIORITY_CLASS, nil, nil, StartupInfo, ProcessInfo) then Result := WAIT_FAILED; end;
procedure einlesen(pfad:string); var sr:TWin32FindData; h:THandle; listitem:TListitem; FileInfo:SHFileInfo; gr:integer; Icon:TIcon; hlp:TListview; begin il.clear; lv.items.clear; hlp:=TLIstview.create(nil); hlp.visible:=false; hlp.parent:=lv; hlp.sorttype:=sttext; Icon:=TIcon.Create; gr:=sizeof(FileInfo); lv.items.beginupdate; h:=FindFirstFile(PChar(pfad+'*.*'),sr);
if h<>INVALID_HANDLE_VALUE then repeat SHGetFileInfo(pchar(pfad+sr.cFileName),0,FileInfo,gr,SHGFI_TypeName or SHGFI_ICON); if FileInfo.szTypeName = 'Verknüpfung' then if sr.dwFileAttributes and FILE_ATTRIBUTE_DIRECTORY = 0 then if sr.dwFileAttributes and FILE_ATTRIBUTE_HIDDEN = 0 then begin listitem:=lv.items.add; listitem.caption:=sr.cFilename; Icon.handle:=FileInfo.hIcon; listitem.Imageindex:=il.addIcon(Icon); end; until Findnextfile(h,sr)=false; Icon.free; hlp.free; lv.items.endupdate; end;
procedure TForm1.FormCreate(Sender: TObject); begin lv := ListView1; il:=TImagelist.create(self); il.Height := 32; il.Width := 32; il.BkColor := ListView1.Color; lv.largeimages:=il; lv.viewstyle:=vsicon; einlesen('C:\Dokumente und Einstellungen\All Users\Startmenü\Programme\'); end;
procedure TForm1.FormDestroy(Sender: TObject); begin lv.free; il.free; end;
procedure TForm1.ListView1MouseDown(Sender: TObject; Button: TMouseButton; Shift: TShiftState; X, Y: Integer); var MyHitTest : THitTests; begin MyHitTest := ListView1.GetHitTestInfoAt(X,Y); if htOnIcon in MyHitTest then begin reason:=true; clickprog:=ListView1.ItemFocused.Caption; end else if htOnLabel in MyHitTest then begin reason:=true; clickprog:=ListView1.ItemFocused.Caption; end else begin reason:=false; clickprog:=''; end; end;
procedure TForm1.ListView1DblClick(Sender: TObject); var progpfad: string; begin if reason = true then begin reason :=false; qrMain.SQL.Text:=('select * from programme where programm = "'+clickprog+'"'); qrMain.Open;
progpfad := qrMain.FieldByName('pfad').AsString;
qrMain.Close; trMain.Disconnect; dbMain.Disconnect;
If progpfad = '' then MessageDlg('Unbekanntes Programm!',mtError,[mbOk],0) else RunProcess(progpfad); end; end; |
Hoffe das Hilft?!
|
|
Christian S.
      
Beiträge: 20451
Erhaltene Danke: 2264
Win 10
C# (VS 2019)
|
Verfasst: Mi 12.02.03 19:55
Hi!
So auf Anhieb kann ich da keinen Fehler sehen. Am Besten erstellst Du mal ein FormClose-Ereignis und setzt dort einen Haltepunkt hinein. Ab dort kannst Du dann mit F7 die einzelnen Anweisungen durchgehen. So kannst Du schon mal lokalisieren, welche Anweisung genau den Fehler auslöst.
Eigentlich hätte ich drauf gewettet, dass Du irgendwo einen Try-Except-Block verwendest, die liefern zur Laufzeit in der IDE nämlich Fehlermeldungen, außerhalb davon nicht.
MfG,
Peter
_________________ Zwei Worte werden Dir im Leben viele Türen öffnen - "ziehen" und "drücken".
|
|
DelphiNoob 
      
Beiträge: 152
Win 2003 Server
D7 Ent
|
Verfasst: Mi 12.02.03 20:06
Vieleicht hilft ja folgendes noch:
Nachdem ich die Exception meldung weggeklickt habe kommen wir ja in den Debugger Mode.
Dort springt er in der Code Ansicht von UNIT1 auf ZTransact. (Ein ZEOS Komponententyp)
Dort wird folgender Block angegangen:
Quelltext 1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12: 13:
| destructor TZTransact.Destroy; begin if Connected then Disconnect; CloseNotifies;
if Assigned(FDatabase) then FDatabase.RemoveTransaction(Self); FQuery.Free; FHandle.Free; FNotifies.Free; inherited Destroy; end; |
Als erstes ist die Zeile "FQuery.Free" betroffen. Kommentiere ich diese aus, dann ist als nächstes "FHandle.Free" der Auslöser. Weiter habe ich es nicht verfolgt, denke aber es geht so weiter...
Nur mal nebenbei gefragt: wenn in der IDE fehler kommen, in Windows aber nicht, ist es dann legitim die Anwendung laufen zu lassen? Bzw frei zu geben? Auch mit Error in der IDE?
Mfg
DelphiNoob
|
|
Christian S.
      
Beiträge: 20451
Erhaltene Danke: 2264
Win 10
C# (VS 2019)
|
Verfasst: Mi 12.02.03 20:37
Hi!
Ist es möglich, dass zu dem Zeitpunkt, zu der ZTransact.Destroy aufgerufen wird, die Komponenten, die von dort aus freigegeben werden sollen (also die aus den Zeilen, die Probleme machen) schon gar nicht mehr existieren?
| Zitat: | | Nur mal nebenbei gefragt: wenn in der IDE fehler kommen, in Windows aber nicht, ist es dann legitim die Anwendung laufen zu lassen? Bzw frei zu geben? Auch mit Error in der IDE? |
Hmmm, ob das legitim ist, kann ich nicht beurteilen. Aber ein Fehler ist und bleibt ein Fehler, egal wo er passiert. Und da ist es eigentlich Ehrensache (ich weiß, hört sich blöd an, aber ich kein besseres Wort gefunden), den zu finden und zu eliminieren. Ich betrachte so etwas immer als persönliche Herausforderung.
MfG,
Peter
_________________ Zwei Worte werden Dir im Leben viele Türen öffnen - "ziehen" und "drücken".
|
|
DelphiNoob 
      
Beiträge: 152
Win 2003 Server
D7 Ent
|
Verfasst: Mi 12.02.03 20:58
Um den ablauf mal aufzuzeigen:
-----------------
Man klickt mit dem Cursor auf ein Item im Listview --> Der Name (Caption) des Item wird in einem Programmweiten String gespeichert --> Es wird eine mySQL Verbindung aufgebaut und abgefragt wie der Pfad des Programmes ist, wo String = Programm ist.
Das Programm wird gestartet. ENDE.
Dann kann das Eigene Programm mit dem Listview auf belieben geschlossen werden.
Der fehler tritt auf.
-----------------
Das ist der grobe ablauf. Ich meine, es werden ja mehrere Items im Listview geaddet. Kann es sein das es dadurch nicht mehr exestiert? Ich hab ja oben den kompletten Source geaddet. Meiner ansicht nach ist dies aber die legitime methodik einen Listview (inkl. ein paar Vorgaben) zu füllen.
Mfg
DelphiNoob
|
|
smiegel
      
Beiträge: 992
Erhaltene Danke: 1
WIN 7
D7 Prof., C#, RAD XE Prof.
|
Verfasst: Mi 12.02.03 21:08
Hallo,
u.U. kann es daran liegen dass Du in der OnCreate lv:=ListView machst und in der Destroy lv.Free.
Das kann nicht funktionieren und wird wahrscheinlich Dein Problem sein.
Du machst im Prinzip nicht's anderes als ListView.Free. Die Listview hast Du wahrscheinlich in der IDE auf die Form gelegt. Wenn dem so ist, so ist Delphi zuständig für das Zerstören der ListView. Es kann also sein, dass in der Destroy, die ListView bereits von Delphi zerstört wurde und ein neuerliches lv.Free den Fehler auslöst.
Wie gesagt eine Vermutung.
_________________ Gruß Smiegel
Ich weiß, daß ich nichts weiß, aber ich weiß mehr als die, die nicht wissen, daß sie nichts wissen. (Sokrates)
|
|
DelphiNoob 
      
Beiträge: 152
Win 2003 Server
D7 Ent
|
Verfasst: Mi 12.02.03 21:09
So, bin gerade mal mit nem Haltepunkt alles abgegangen!
So wie es aussieht liegt das problem in der mysql komponente.
Wie ich oben schon beschrieb liegt der Fehler an einer Zeile die folgende Prozedur beinhaltet:
Quelltext 1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12: 13: 14: 15:
| procedure TZDatabase.RemoveTransaction(Transact: TObject); var N: Integer; begin try N := FTransacts.IndexOf(Transact); if N >= 0 then try TZTransact(FTransacts[N]).Disconnect; finally FTransacts.Delete(N); end; except end; end; |
Wie dort zu sehen ist, ist auch eine try finally und expect funktion vorhanden.
Meinungen?
|
|
DelphiNoob 
      
Beiträge: 152
Win 2003 Server
D7 Ent
|
Verfasst: Mi 12.02.03 21:10
@ smiegel!
Ich teste es, mag sein... hatte gleichzeitig gepostet!
|
|
smiegel
      
Beiträge: 992
Erhaltene Danke: 1
WIN 7
D7 Prof., C#, RAD XE Prof.
|
Verfasst: Mi 12.02.03 21:11
Hallo,
habe ich glatt vergessen: entferne das lv.Free aus der Destroy.
_________________ Gruß Smiegel
Ich weiß, daß ich nichts weiß, aber ich weiß mehr als die, die nicht wissen, daß sie nichts wissen. (Sokrates)
|
|
DelphiNoob 
      
Beiträge: 152
Win 2003 Server
D7 Ent
|
Verfasst: Mi 12.02.03 21:11
Leider liegt es nicht daran smiegel...
Er schaltet weiterhin in die MySQL Komponente um. Denke liegt irgendwo da.
|
|
DelphiNoob 
      
Beiträge: 152
Win 2003 Server
D7 Ent
|
Verfasst: Mi 12.02.03 21:13
Er geht immer zu folgender stelle in die MySQL Komponente:
Quelltext 1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12: 13:
| destructor TZTransact.Destroy; begin if Connected then Disconnect; CloseNotifies;
if Assigned(FDatabase) then FDatabase.RemoveTransaction(Self); FQuery.Free; FHandle.Free; FNotifies.Free; inherited Destroy; end; |
Speziell zu: FQuery.Free;
|
|
Christian S.
      
Beiträge: 20451
Erhaltene Danke: 2264
Win 10
C# (VS 2019)
|
Verfasst: Mi 12.02.03 21:25
Ich glaube, es liegt an dem Try-Except-Block. Fehler, die im normaler Programmablauf völlig korrekt von einem solchen abgefangen werden, meldet Delphi trotzdem noch, wenn das Programm in der IDE läuft.
Es könnte an Folgendem liegen:
Du führst in TZTransact.Destroy manuell ein DisConnect aus. Aber es wird nachher noch dieser Code aufgerufen:
Quelltext 1: 2: 3: 4: 5: 6:
| try TZTransact(FTransacts[N]).Disconnect; finally FTransacts.Delete(N); end; except |
Hier könnte Disconnect eine Exception auslösen, weil ja schon nicht mehr verbunden ist. Wenn es wirklich an dieser Try-Except-Anweisung liegt, wird der Fehler eigentlich normal abgefangen und Du musst Dich nicht mehr drum kümmern.
Du kannst diese Meldungen irgendwo in Delphi abschalten (also, dass Delphi behandelte Exceptions anzeigt), aber ich weiß nicht mehr wo. Ich werde mal suchen und wenn ich die Stelle finde, sage ich Bescheid.
MfG,
Peter
edit{
Hab's gefunden: Debugger Optionen --> Sprach-Exceptions --> Bei Delphi-Exceptions stoppen
}
_________________ Zwei Worte werden Dir im Leben viele Türen öffnen - "ziehen" und "drücken".
|
|
DelphiNoob 
      
Beiträge: 152
Win 2003 Server
D7 Ent
|
Verfasst: Mi 12.02.03 21:28
Gut... meine Mundwinkel krümmen sich langsam wieder in Richtung "fröhlichkeit"!
Ich teste auch mal rum wo man es abschalten kann!
|
|
DelphiNoob 
      
Beiträge: 152
Win 2003 Server
D7 Ent
|
Verfasst: Mi 12.02.03 21:32
Habs:
Du gehst auf Tools -> Debugger Optionen -> Sprach Exceptions -> Hinzufügen.
Funzt!
|
|