Hallo NG,
ich habe mit VS 2008 ein Projekt erstellt, dass aus einer einzigen Form ohne
Steuerelemente und nur mit einem Listlabel14 Object versehen ist. Beim
Schliessen des Programmes erhalte ich folgende Meldung des Debuggers:
"
CMLL14 : 13:50:42.515 0000129c LlJobClose(1)
CMCT14 : 13:50:42.515 0000129c WRN: window cannot be destroyed (Zugriff
verweigert (00000005) - [calling thread differs from creation thread!]),
trying to close it.
"
Ich habe dieses Miniproject nur erstellt, um festzustellen, ob LL14 den
Speicher sauber freigibt. Hat jemand von euch ähnliche Erfahrung ? Ich habe
das neuste SP installiert.
Ist das wirklich ein Speicherproblem, oder stört Dich nur diese
Warnung?
Im DEBWIN geben manche LLX-Erweiterungen auch an, daß sie ‘lost
objects’ haben, wenn diese DLLs freigegeben werden, aber da die Zahl
konstant bleibt (egal wieviel man das LLX nutzt: immer 14 Objekte) und
die Heaps von DLLs vom Betreibssystem beim Entladen freigegeben
werden, würde ich annehmen, daß es nicht ernsthaft ein Leak ist.
→ besser: Support.
Außerdem: Bitte rufe das Dispose() des Cores auf, wie man das machen
soll, wenn ein Objekt “disposable” ist. Der GarbageCollector ist kein
“idealer” Platz, um das Objekt entsorgen zu lassen.
Paulchen
“Wolfgang Ahrens” <wahrens@w…> wrote in message
news:28975422200914045@combit.net…
Hallo NG,
ich habe mit VS 2008 ein Projekt erstellt, dass aus einer einzigen
Form ohne
Steuerelemente und nur mit einem Listlabel14 Object versehen ist.
Beim
Schliessen des Programmes erhalte ich folgende Meldung des
Debuggers:
"
CMLL14 : 13:50:42.515 0000129c LlJobClose(1)
CMCT14 : 13:50:42.515 0000129c WRN: window cannot be destroyed
(Zugriff
verweigert (00000005) - [calling thread differs from creation
thread!]),
trying to close it.
"
Ich habe dieses Miniproject nur erstellt, um festzustellen, ob LL14
den
Speicher sauber freigibt. Hat jemand von euch ähnliche Erfahrung ?
Ich habe
das neuste SP installiert.
interessanterweise tritt der Hinweis nur auf, wenn ich das Object mit der Toolbox generiere.
Mit “NEW ll as” und “ll.dispose” ist es kein Problem.
Wolfgang
Ist das wirklich ein Speicherproblem, oder stört Dich nur diese
Warnung?
Im DEBWIN geben manche LLX-Erweiterungen auch an, daß sie ‘lost
objects’ haben, wenn diese DLLs freigegeben werden, aber da die Zahl
konstant bleibt (egal wieviel man das LLX nutzt: immer 14 Objekte) und
die Heaps von DLLs vom Betreibssystem beim Entladen freigegeben
werden, würde ich annehmen, daß es nicht ernsthaft ein Leak ist.
→ besser: Support.
Außerdem: Bitte rufe das Dispose() des Cores auf, wie man das machen
soll, wenn ein Objekt “disposable” ist. Der GarbageCollector ist kein
“idealer” Platz, um das Objekt entsorgen zu lassen.
Paulchen
“Wolfgang Ahrens” <wahrens@w…> wrote in message
news:28975422200914045@combit.net…
Hallo NG,
ich habe mit VS 2008 ein Projekt erstellt, dass aus einer einzigen
Form ohne
Steuerelemente und nur mit einem Listlabel14 Object versehen ist.
Beim
Schliessen des Programmes erhalte ich folgende Meldung des
Debuggers:
"
CMLL14 : 13:50:42.515 0000129c LlJobClose(1)
CMCT14 : 13:50:42.515 0000129c WRN: window cannot be destroyed
(Zugriff
verweigert (00000005) - [calling thread differs from creation
thread!]),
trying to close it.
"
Ich habe dieses Miniproject nur erstellt, um festzustellen, ob LL14
den
Speicher sauber freigibt. Hat jemand von euch ähnliche Erfahrung ?
Ich habe
das neuste SP installiert.
Ja, dann räumt der Garbage Collector auf, und der ist in einem anderen
Thread.
→ besser nicht so machen.
Sagt
Paulchen (der sich aber nicht mit .NET auskennt, ich lasse mich gern
eines besseren belehren)
“Wolfgang Ahrens” <wahrens@w…> wrote in message
news:32124222009185149@combit.net…
Danke Paul,
interessanterweise tritt der Hinweis nur auf, wenn ich das Object
mit der Toolbox generiere.
Mit “NEW ll as” und “ll.dispose” ist es kein Problem.
Wolfgang
Ist das wirklich ein Speicherproblem, oder stört Dich nur diese
Warnung?
Im DEBWIN geben manche LLX-Erweiterungen auch an, daß sie ‘lost
objects’ haben, wenn diese DLLs freigegeben werden, aber da die
Zahl
konstant bleibt (egal wieviel man das LLX nutzt: immer 14 Objekte)
und
die Heaps von DLLs vom Betreibssystem beim Entladen freigegeben
werden, würde ich annehmen, daß es nicht ernsthaft ein Leak ist.
→ besser: Support.
Außerdem: Bitte rufe das Dispose() des Cores auf, wie man das
machen
soll, wenn ein Objekt “disposable” ist. Der GarbageCollector ist
kein
“idealer” Platz, um das Objekt entsorgen zu lassen.
Paulchen
“Wolfgang Ahrens” <wahrens@w…> wrote in message
news:28975422200914045@combit.net…
Hallo NG,
ich habe mit VS 2008 ein Projekt erstellt, dass aus einer
einzigen
Form ohne
Steuerelemente und nur mit einem Listlabel14 Object versehen ist.
Beim
Schliessen des Programmes erhalte ich folgende Meldung des
Debuggers:
"
CMLL14 : 13:50:42.515 0000129c LlJobClose(1)
CMCT14 : 13:50:42.515 0000129c WRN: window cannot be destroyed
(Zugriff
verweigert (00000005) - [calling thread differs from creation
thread!]),
trying to close it.
"
Ich habe dieses Miniproject nur erstellt, um festzustellen, ob
LL14
den
Speicher sauber freigibt. Hat jemand von euch ähnliche Erfahrung
?
Ich habe
das neuste SP installiert.
