XbpColumn:status [Erledigt]

[Jan]

Moin,

ich kämpfe gerade mit einem seltsamen Phänomen. Ein Browse wird in einem Thread erstellt mit den entsprechenden Spalten. Der Thread wird beendet. Wenn ich den Thread noch einmal starte wird der Browse automatisch neu erstellt. Soweit alles klar. Aber wenn ich dann wieder die Spalten erstellen will gibt es einen Laufzeitfehler. Weil der Status der gerade zu erstellenden Spalte falsch ist. :status gibt mir hier eine 0 zurück - beim ersten Durchlaiuf war das noch korrekt eine 1.

Stellt sich mir die Frage warum der 0 ist. Alle Codezeilen sind wie beim ersten Erstellen auch sauber durchgelaufen. Auch der Browse selber wurde korrekt erzeugt. Nur die Spalten wollen angeblich nicht.

Das Errorlog ist:

Code: Alles auswählen

oError:args         :
          -> VALTYPE: O CLASS:XbpColumn
          -> VALTYPE: U VALUE:NIL
          -> VALTYPE: O CLASS:XbpStatic
          -> VALTYPE: U VALUE:NIL
          -> VALTYPE: A VALUE:{0, 0}
          -> VALTYPE: U VALUE:NIL
          -> VALTYPE: L VALUE:.F.
oError:canDefault   : .F.
oError:canRetry     : .F.
oError:canSubstitute: .T.
oError:cargo        : NIL
oError:description  : Falscher Objekt Status
oError:filename     : 
oError:genCode      : 104
oError:operation    : :Create
oError:osCode       : 0
oError:severity     : 2
oError:subCode      : 4208
oError:subSystem    : BASE
oError:thread       : 6
oError:tries        : 0

Jan

[Tom]

Hallo, Jan.

Ich kenne das, dass ein Objekt hin und wieder unmittelbar nach dem Create (noch) nicht den Status XBP_STAT_CREATE (1) hat, aber ich kenne das bislang noch nicht wiederkehrend oder gar nachstellbar. Wenn das wirklich jedes Mal passiert, schleppst Du irgendwie Reste mit Dir herum.

[Jan]

Hallo Tom,

genau das irritiert mich ja. Es ist reproduzierbar. Alle Objekte in dem Thread sind LOCALs. Und ich destroye vorsichtshalber vor dem oThread:quit() alle Objekte in dem Thread. Nur die Spalten, die spielen da irgend wie nicht mit.

Jan

[Slavko]

Hallo Jan,

Dies liegt daran, dass Alaska den Thread mit der Funktion TerminateThread() und nicht mit der Funktion ExitThread() beendet. MSDN erklärt Folgendes zum Beenden von Threads:

TerminateThread is a dangerous function that should only be used in the most extreme cases. Terminating a thread does not necessarily remove the thread object from the system. A thread object is deleted when the last thread handle is closed.
The TerminateThread function does not allow thread to clean up, do not notify attached DLLs, and do not free the initial stack. If the target thread is allocating memory from the heap, the heap lock will not be released.

Mit anderen Worten: Wenn Sie alle Objekte vor dem Beenden des Threads zerstören, zerstört das System diese nicht. Dies geschieht erst beim Beenden des aktuellen Prozesses (Programms) beenden und der Thread tatsächlich zerstört wird. Dasselbe passiert mit allen lokalen Variablen.

[Tom]

Wenn alle Objekte LOCAL waren und ein Thread beendet sich durch ein schlichtes RETURN, dürfte das ganze sauber sein - so ist es bei uns jedenfalls seit Jahrzehnten. Thread:Quit() verwenden wir überhaupt nicht (das wäre m.E. auch nur dazu geeignet, einen laufenden Thread von außen zu beenden), und wir verwenden :atEnd auch nur, um L&L-Druckjobs zu schließen. Was machst Du da genau, Jan?

[Slavko]

Hallo Tom,

Wie Sie wissen, ist ein Thread kein Programm (Prozess) und hat kein RETURN. Daher werden bei Thread-Beendigung in Alaska lokale Variablen NICHT zerstört, und jede Thread-Beendigung verursacht einen Speicherverlust. Dasselbe gilt für private Variablen und deren RELEASE. Sie können in einem Memory Watcher sehen, dass der Speicherverbrauch Ihrer Anwendung steigt, wenn Sie eine große Anzahl von Threads mit vielen lokalen/privaten Variablen erstellen.

[Tom]

Hallo, Slavko.

Wenn ich in der Start-Methode eines Threads einen Programmteil aufrufe, läuft dieser im fraglichen Thread. Wenn sich dieses Programmteil mit RETURN beendet, terminiert sich der Thread. Er ist dann auch nicht mehr als Prozess vorhanden und all seine Ressourcen sind freigegeben (es sei denn, man hat im Code ordentlich Mist gebaut). Ich verwendet eine abgeleitete eigene Thread-Klasse, die im atEnd u.a. dafür sorgt, dass alle L&L-Druckjobs geschlossen werden. atEnd wird ausgeführt, wenn der Code im Codeblock (z.B. mit RETURN) beendet wurde. Alles fein.

[Slavko]

Hallo Tom,

Dem stimme ich voll und ganz zu. Ich verwende dieselben Szenarien. Aber was Sie sagen:

Wenn sich dieses Programmteil mit RETURN beendet, terminiert sich der Thread. Er ist dann auch nicht mehr als Prozess vorhanden und all seine Ressourcen sind freigegeben.

Das ist zwar theoretisch so, aber in der Praxis passiert es nicht genau so. Stattdessen passiert das, was ich aus MSDN zitiert habe. Ich mag das nicht und konnte es kaum glauben, aber durch Experimente mit großen Threads konnte ich mich davon überzeugen. Das Beste ist, im Thread-Prozess keine großen Variablen und Objekte zu erstellen, sondern so wenig Variablen/Speicher wie möglich zu verwenden.

[RolandG]

Das Beste ist, im Thread-Prozess keine großen Variablen und Objekte zu erstellen, sondern so wenig Variablen/Speicher wie möglich zu verwenden.

Sehr seltsam... also doch am besten für wichtige Dinge eine neue EXE starten...

[Tom]

Das Beste ist, im Thread-Prozess keine großen Variablen und Objekte zu erstellen, sondern so wenig Variablen/Speicher wie möglich zu verwenden.

Das kann ich nicht bestätigen. Wir stecken sehr große Module in Threads, ganz ohne Probleme (eigentlich stecken wir jedes Modul in einen Thread, anders ließe sich das MDI-Konzept unserer Anwendung nicht verwirklichen). Wir führen gelegentlich Tests durch oder schauen uns mit VMMap an, wie die Speichernutzung aussieht, und das ist alles sehr robust und keine Fehlerquelle. Wir hatten mit den Stack-Zuweisungen für die Threads herumgespielt, aber auch das erwies sich als überflüssig (Alaska hat uns hier sehr geholfen). In einigen Situationen begrenzen wir die Anzahl der Threads, aber das geschieht eher auf Wunsch der jeweiligen IT als aufgrund einer Notwendigkeit.

[RolandG]

Stattdessen passiert das, was ich aus MSDN zitiert habe.

Was hat jetzt MSDN mit den von Xbase++ erstellten Threads zu tun?
Bei der "Wiederverwendung" eines (stillgelegten?) Threads könnte ich mir das vorstellen.
Aber bei einem neuen Thread sollen Objekte aus einem vorherigen, gelöschten Thread Probleme machen...?

[Tom]

Ich verstehe nicht ganz, wie Jan mit Threads arbeitet. Thread:Quit() macht man normalerweise von außen. Bei dem Anwendungskonzept, das wir nutzen, ist das völlig unnötig. Aber ich glaube nicht, dass Jans Problem mit dem MSDN-Eintrag zu tun hat.

[Slavko]

Ich wollte nur mein Wissen und meine Erfahrungen mit Threads teilen. Natürlich hast du deine eigenen, und das ist in Ordnung, keine verletzten Gefühle.
Und ich vertraue MSDN, sie wissen mit Sicherheit, was sie geschrieben haben und warum.

[Tom]

Wessen Gefühle wurden oder werden hier verletzt?

[Jan]

Moin,

ich bin gerade unterwegs und kann daher keinen Code raus suchen.

Das Programm läuft so das die meisten Funktionen auf TabPages liegen. Und das Aktivieren einer TabPage startet den dazu gehörigen Thread. Auf manchen TabPages gibt es einen Schließen-Button. Wird der angeklickt wird der gesamte TabPage aufgeräumt - Tabellen sauber schließen, Children destroyen, den TabPage deaktivieren, und den Thread beenden per :quit(). Das läuft so schon seit vielen Jahren.

Ich habe jetzt aus verschiedenen Gründen bei einer ganzen Reihe von Funktionen die Anzeige von einer XbpListbox zu einem XbpBrowse geändert. Und seither habe ich dieses Problem. Und nur mit den XbpColumns. Die XbpBrowse und andere XBP auf den TabPages laufen ganz sauber.

Was ich nicht verstehe ist der Einwand von Slavko. Ja, ich kenne die Geschichte das man einen Thread reaktivieren kann. Aber wenn ich doch alle XBP (die alle LOCAL sind) destroye, dann kann doch auch ein Reaktivieren des Threads die nicht wieder hervor holen?

Jan

[Marcus Herz]

XbpColmuns starten noch einen eigenen Thread für die Anzeige. Aber damit kanns ja auch nicht zusammenhängen. Hast du da auffällige codeblocke?

[Jan]

Es scheint so als ob ich das Problem gefunden habe.

Neben den Schließen-Button gibt es noch einen weiteren, der Überprüfung der Daten auslöst. Und in dem Codeblock dieses Buttons habe ich nach dem Auslösen der Prüffunktion noch ein SetAppWindows(oBrowse) drin stehen gehabt. Das stand da schon immer drin, schon in Zeiten als das noch eine XbpListbox war. Natürlich ist der Aufruf kompletter Blödsinn, das hätte SetAppFocus(oBrowse) sein müssen. Aber seit Jahren steht das da schon, und hat nie geschadet. Also bin ich da auch nie drüber gestolpert. Erst jetzt nach dem Umbau auf den XbpBrowse hat das durchgeschlagen.

Wobei ich mich frage warum erst im zweiten Durchlauf, und warum da erst beim :create auf die XbpColumn. Warum nicht schon beim Browse oder den Buttons?

Danke für Eure Tipps und Hinweise.

Jan