| |
| |
|
Rainer
Hoefs | Hallo,
schreibe gerade ein Rechnungsprogramm für meine Frau. Ich benutze darin 2 Datenbanken *.DBF.
Einmal die mit den Kundenadressen und eine in der die Rechnungsdaten gespeichert werden.
Die Rechnung wird in einem Preview-Fenster immer aktuell gezeigt, und auch so gedruckt.
Das alles funktioniert einwandfrei.
Nun habe ich einen Button, der die KundenDB im dbBrowse anzeigt, editiert usw.
Das funktioniert im RunModus absolut fehlerfrei.
In der kompilierten Exe schmiert das Programm grundsätzlich ab, und ich kann nicht feststellen warum?!
Der gleiche Aufrauf mit der selben DB funktioniert in einem Minimalprogramm auch in der EXE tadellos.
Wie kann ich den Fehler finden??
Danke für die Hilfen.
Rainer |
|
| |
| |
| |
|
|
Michael
W. | ErrorProc,
LogDatei (über 27.1 Fehlermeldungen),
externer Debugger (auch über 27.1 erreichbare Info)
Leider zu wenig Input um da aus der Hüfte zu schiessen... |
|
| |
| XProfan X3System: Windows 8/10, XProfan X4 Programmieren, das spannendste Detektivspiel der Welt. | 05.07.2015 ▲ |
|
| |
|
|
Rainer
Hoefs | Vielen Dank für den Hinweis,
aber das was Du da schreibst sind für mich einfach böhmische Dörfer, was ist mit (über 27.1 Fehlermeldungen) zu verstehen.
Mit dem externen Debugger komme ich überhaupt nicht klar, habe die Hilfe schon zig-mal gelesen und verstehe nicht was ich...
a. im Programm machen muß, damit der funktioniert...
b. ich mit dem Debugger machen muß um eine Exe, die nicht funktioniert zu starten. Der Code läuft auch im Debugger im Runmodus einwandfrei.
Also Du siehst hier einen totalen Hilflosen.
Trotzdem Danke
Rainer |
|
| |
| |
| |
|
|
Michael
W. | Hilfedatei Kapitel 27.1
Set("LogFile","c:\XProfan\Logbuch.txt")
Mit LogOut "string" dann wegschreiben was in Variablen stand, oder wo man gerade im Programm ist. Da diese Datei immer gleich wieder geschlossen wird, kann sie nach einem Absturz genau sagen bis wohin das Programm es geschafft hat.
a
Set("Errorlevel",1) 'Fehler/Warnungen im Debugger zeigen
' hiermit sieht man, wann der Abflug passiert
Set("DebugMode",2) 'Einzelschritt im Debugger
b
Im Einzelschritt abarbeiten und schauen, was so in den Variablen steht. Also wie ein Detektiv an den Fehler herantasten.
LogOut ist übrigens die einfachste Methode der Eingrenzung. Da es nur in der EXE zum Abflug kommt, einfach "Wegpunkte" setzen und im Logbuch dann schauen, welcher letzte Punkt es noch ins Logbuch geschafft hat.
Danach kann der Fehler nicht sein, aber eine ganze Weile davor.
Z.B. wird etwas in Datei geschrieben, was einen IO-Fehler erzeugt. Dann kann es passieren, das erst der nächste Zugriff auf die Nase fällt.
LogOut "Hauptprogramm Start"
LogOut "Untermodul Daten lesen Start"
LogOut "Untermodul Daten lesen Ende"
LogOut "Daten zeigen"
LogOut "Tastendruck für ..."
LogOut "Daten schreiben"
LogOut "Untermodul Daten lesen Start"
LogOut "Untermodul Daten lesen Ende"
LogOut "Untermodul Datensatz löschen Start"
LogOut "Untermodul Datensatz löschen ausführen"
...
(Mal so als Beispiel. Ist natürlich an den entsprechenden Stellen einzufügen.)
Man wandelt also alles was man zum aktuellen Stand wissen möchte in einen String und schreibt es ins Logbuch.
Beim Debugger gibt es noch Dateien auf der Platte
PrfDebug*.(inc/prf)
Die können auch bei der Analyse helfen. |
|
| |
| XProfan X3System: Windows 8/10, XProfan X4 Programmieren, das spannendste Detektivspiel der Welt. | 06.07.2015 ▲ |
|
| |
|
|
Rainer
Hoefs | Danke für Deine verständliche Erklärung.
Ich werde es mal ausprobieren.
Rainer |
|
| |
| |
| |
|
|
Thomas
Freier | Riecht nach Zugriffsverletzung.
Gehe davon aus, dass nicht gleichzeitig versucht wird RE zu schreiben und Daten zu editieren.
Persönlich öffne ich zu jeder Aktion die dbf neu und schließe sie wieder sofort (alte dbase-dos-zeiten Macke) wenn die Aktion abgeschlossen ist.
Zeitverlust habe ich noch nicht feststellen können.
Im Prinzip ist es ja möglich alle dbf am Programmanfang zu öffnen und erst mit dem Programmende zu schließen. Aber ob das immer rund läuft? |
|
| |
| |
| |
|
|
RGH | Wenn ein Programm im Interpreter läuft, aber kompiliert abstürzt, kann es auch ein kleiner Syntaxfehler sein, den der Interpreter toleriert und übersieht, der aber das Runtime-Modul zum Absturz bringt. Das kann z.B. ein doppeltes Komma oder ein überflüssiger Parameter sein.
Ich weiß, dass es solche möglichen Fehler, gibt und habe auch schon einige ausgebügelt. Naturgemäß sind die Parser von Interpreter und Runtime nun mal unterschiedlich und daher kann so etwas vorkommen.
Solltest Du also den Fehler mit obigen Methoden gefunden haben, wäre ich für einen Hinweis dankbar, um ein solch unterschiedliches Verhalten künftig zu vermeiden.
Gruß
Roland |
|
| |
| XProfan X2Intel Duo E8400 3,0 GHz / 4 GB RAM / 1000 GB HDD - ATI Radeon HD 4770 512 MB - Windows 7 Home Premium 32Bit - XProfan X4 | 06.07.2015 ▲ |
|
| |
|
|
Rainer
Hoefs | Hallo Roland,
habe das Problem ersteinmal mit einem eigenen Dialog gelöst. der funktioniert so wie er soll und macht keinen Fehler
Wenn ich wieder etwas Zeit habe schaue ich da nochmals rein und werde mich melden wenn ich etwas gefunden habe.
Danke
Rainer |
|
| |
| |
| |
|
(860)
Deutsch
English
Français
Español
Italia