Hi,
Zitat von
Uwe Raabe:
Probier doch mal dies:
Delphi-Quellcode:
procedure TestPrinter;
var
i: Integer;
begin
for i := 1 to 100 do
begin
Printer.BeginDoc;
Printer.EndDoc;
SetPrinter(nil).Free;
end;
end;
Nur so 'ne Idee...
Gute Idee, aber leider gleiches Ergebnis: Ich hab jetzt schon versucht Brother zu kontaktieren, aber kommt nur der 08/15 "Kundenservice" - der natürlich von sowas keine Ahnung hat. Ich kann das Leak jetzt auf die Datei BROMF04B.dll zurückführen, den Brother Printer Driver 0.3.0.0 (v3.23). Es leaken die weiter obene aufgeführten Objekte.
Da wird ein (Kernel)objekt in der Benutzersession einfach nicht wiederverwendet, sondern pro Druckauftrag angelegt. Wie man das für manche HP- und Brothertreiber generell fixen kann ist eine gute Frage...
Zitat von
nahpets:
ob man aktiv Leaks, die andere produzieren, vermeiden kann, wage ich zu bezweifeln.
...
Was mir vorschwebt wäre eine Methode, die am Anfang einer Routine die Zahl der
Handle (ggfls. auch eine Handleliste) zum eigenen Prozess erstellt. Dann wird die Routine ausgeführt und eine erneute Prüfung durchgeführt. Die Differenz zwischen vorher und nachher müsste man dann selbst aufräumen.
Das ist jetzt sicherlich erstmal eine sehr naive Sicht, von der ich momentan nicht weiß, ob und ggfls. wie sie zu realisieren ist.
Richtige Überlegung, wobei es an sich ja nicht Aufgabe des einen Programmierers sein kann, dynamische Probleme eines anderen auszugleichen. Wenn es jetzt um ein generelles Problem mit einem Betriebssystem geht, nun gut, dann muß man das nunmal machen. Aber bei Leaks anderer Anwendungen ist ja auch Vorsicht geboten:
Man greift in Abläufe ein, die sich u.U. durch neue Treiber oder Anwendungsversionen ändern. Dies kann dann im Gegenzug Probleme verursachen.
Ein Cleanup-Code wie Du Ihn vorgeschlagen hast wäre schon der richtige Ansatz. Die Handles ließen sich ja auch von Delphi aus löschen. Aber wenn man das so machen müßte, liefe mir irgendwie ein kalter Schauer über den Rücken...
Zitat von
nahpets:
[
OT]befürchte, dass ich schon wieder keine Antwort gebe, sondern weitere Fragen aufwerfe
[/
OT]
Macht ja nichts
Ich überlege derzeit wie ich die problematischen Codeteile, hier den Druck, in einen Childprozess auslagere ohne zusätzliche Hüren zu schaffen.
Bevor ich jetzt das Rad neu erfinde: Kenn jemand ein Beispiel für einen Child-Process zum Drucken?
Zum Drucken wird der Child gestartet, Druckdaten übergeben, der Druck ausgeführt und ein Returncode (und -message) gesendet. Nach jedem Druck wird der Child terminiert, so sollte auch das
Handle zerstört werden. Sehe ich das jetzt richtig, oder trügt mich meine Erinnerung?
Gruß Assertor