Unerwartetes Programmende ohne Error.Log oder XppFatal.Log

[UliTs]

Hallo allerseits,

ich habe derzeit das Problem, dass sich ein xBase-Programm in meiner Testumgebung des öfteren einfach so beendet und zwar
- ohne Bildschirmfehlermeldung
- ohne Error.log-Eintrag
- ohne XppFatal.log-Eintrag

Ich habe kaum eine Ahnung, warum...
Ich vermute, es hat mit Drucken oder der Auswahl des Druckers zu tun...
---
Kennt jemand auch das Verhalten, dass sich xBase-Programme ohne erklärlichen Grund ohne Fehlermeldung etc. beendet?
Wann tritt es bei Euch auf?
---

Uli

[Rolf Ramacher]

Hi Uli

vielleicht läuft das Programm bei irgendeiner Schnleife zum Ende hin und das Programm wird normal beendet -
steht irgendwo ein "quit" ?

[UliTs]

Quit ist für mich ein erklärliches Ende

Uli

[AUGE_OHR]

hi,

ohne Test Code kann man da kaum beurteilen.
Ich würde ein "Logbuch" einbauen um das Problem weiter einzugrenzen.

verwendest du, an der Stelle, evtl 3-PP, DLLCall oder activeX ?

[Jan]

Uli,

ich hatte auch schon die Situation, das ich keine xppfatal hatte. Bis ich merkte, das die sehr wohl da ist, nur in einem anderen Pfad. Durchsuch doch mal Deine Festplatte nach dem Dateinamen, vielleicht hat die sich ja nur vor Dir versteckt

Jan

[UliTs]

Hallo Jimmy,
Hast Du den Fall schon einmal gehabt?

Hallo Jan,
Gute Idee!
Eigentlich lasse ich die xppfatal.log immer ins gleiche Verzeichnis schreiben.
Aber wer weiß ...

Uli

[Hans Zethofer]

Hallo,

Ich habe auch so unerklärliche Vorgänge gehabt vor der möglichen Auswahl des Druckerfensters.
Bei mir war es beim "DCPRINT ON" Befehl (es kam dann keine Druckerauswahl mehr sondern der Ausstieg aus dem Programm)

Abhilfe hat ein DC_MSGBOX("irgendein Texthinweis") unmittelbar vor dem "DCPRINT ON" gebracht - einfach eine Wartepositionsmeldung.
Nachdem das Programm dort 1 Sekunde gewartet hatte kam das Auswahlfenster immer - ohne Meldung war es eine Lotterie.

Damit kann ich derzeit gut leben

[AUGE_OHR]

Hast Du den Fall schon einmal gehabt?

leider öfter als mir lieb ist.
Es passiert bei mir in der Kombination mit Thread das ich keine XppError.LOG bekomme ... dann wieder XppError.001 oder gar nichts ...

bei activeX hat man ja noch den GUI Thread in dem die laufen.
wenn das activeX dann noch im Thread läuft und dann ein "timeing" Fehler entsteht ist die Wahrscheinlichkeit sehr gross das du keine XppError.LOG bekommst

in solchen Fällen hab ich dann ein Demo ohne Thread gebaut, alles in BEGIN SEQUENCE gepackt, Logbuch eingebaut und dann erst den Fehler gefunden.

[UliTs]

bei activeX hat man ja noch den GUI Thread in dem die laufen.

Wenn ich es richtig verstanden habe, ist der GUI Thread ein Thread vom Betriebssystem, der immer (unabhängig vom Programm) läuft, oder?
Ich benutze die XbpPdf-Komponente. Vielleicht hängt es damit zusammen.

Hans,
ich vermute, DCPRINT ON ist in einem externen Tool enthalten? Was macht es genau?

Uli

[Hans Zethofer]

ja - in eXpress++

damit beginnt die Grunddefinition des Druckjobs

Code: Alles auswählen

DCPRINT ON SIZE 50,90 FONT '9.Terminal' TO oPrinter

[UliTs]

ja - in eXpress++

damit beginnt die Grunddefinition des Druckjobs

Code: Alles auswählen

DCPRINT ON SIZE 50,90 FONT '9.Terminal' TO oPrinter

Wie sieht der zugehörige xBase-Code aus (das, was der Präprozessor daraus mach)?

Uli

[Hans Zethofer]

Diese Befehlssequenze

Code: Alles auswählen

      DCPRINT ON ;
         SIZE 66,103.700; 
         FONT '9.Courier New' ;
         TO oPrinter ;
         FORMSIZE XBPPRN_FORM_A4

wird so übersetzt

Code: Alles auswählen

oPrinter :=  DC_PrinterOn( { ,  ,  ,  66,  103.700,  ,  .F. ,  .F. ,  .F. ,  ,  '9.Courier New',  nil,  .F. ,  .F. ,  .F. ,  ,  nil,  ,  .F. ,  ,  ,  ,  ,  ,  ,  ,  ,  .F. ,  ,  .F. ,  IIF(.F.,1,0) + IIF(.F.,2,0),  ,  nil,  nil,  nil,  ,  ,  !.F. ,  .F. ,  ,  9,  !.F. ,  .F. , ,  .F. ,  .F. ,  .F. ,  ,  .F. ,  ,  ,  ,  !.F. ,  .F. ,  .F. ,  ,  .F. ,  ,  .F. ,  .F. ,  ,  .F. ,  .F. ,  .F. ,  ,  .F.  },  )

[Manfred]

Ich denke mal, da wird Uli jetzt vor Euphorie an die Decke springen.

[AUGE_OHR]

bei activeX hat man ja noch den GUI Thread in dem die laufen.

Wenn ich es richtig verstanden habe, ist der GUI Thread ein Thread vom Betriebssystem, der immer (unabhängig vom Programm) läuft, oder?
Ich benutze die XbpPdf-Komponente. Vielleicht hängt es damit zusammen.

Tja ich "denke" da hätten wir das "Problem".

ich "tippe" mal darauf das dass "Timing" nicht stimmt und dann eine Method oder iVar "nicht erreichbar" ist.

[Hans Zethofer]

seh ich auch so - da mit einem wait von 1 sec das problem nicht mehr auftaucht.

[Magic]

Guten Morgen,

falls es doch nichts mit Thread & Drucken zu tun haben sollte:
Bei mir habe ich solche ein Verhalten (Programmabbruch ohne Fehlermeldung & log) wenn ich in ein Array Datensätze schreibe & die Kapazität des Array (hat das eigentlich was mit dem RAM des Rechners zu tun?) anscheinend gesprengt wird.
Im konkreten fall machen die Benutzer eine Vorauswahl & anschließend wird ein Array gefüllt.
Je nach Auswahl können es mehrere tausend, aber auch mehr als 1-2 Millionen Datensätze sein.
Irgendwann (beim füllen das Arrays) war dann plötzlich das Programm weg. Ohne jegliche Meldung.
Hat ein wenig gedauert bis ich es genau lokalisieren konnte.
Es war kein Einzelfall.

[brandelh]

Hi,

einige 1000 oder 10000 Einträge in einem Array sind auf einem halbwegs aktuellen Rechner kein Problem,
aber Millionen Einträge, das ist zuviel - natürlich kommt es noch darauf an wieviel Byte ein Arrayelement benötigt.
Es liegt übrigens nicht nur am tatsächlichen Verbrauch, sondern auch an der Art wie sie angelegt werden.

Einfach mal nach ARRAY* suchen, dort gibt es einige Threads zu großen Arrays.

[Jan]

Wenn man wirklich viele Elemente in ein Array einlesen möchte, dann steigt Xbase++ definitiv aus. Ich lese in einem Projekt mehrere 100.000 Elemente ein, und bekam ständig Laufzeitfehler. Alaska hat mir auf Anfrage eine neue dll geschickt, mit der man das einstellen kann (nicht zu hoch, da dann Performanceverlust. Angeblich. Konnte ich selber bislang nicht beobachten). Einfach mal bei Alaska nachfragen.

Jan