![]() |
Speicherleck in WinSpool.OpenPrinter API ???
Habe folgendes Problem, mit einem Timer wird die u.a. Funktion alles 5 sek aufgerufen, soweit so gut.
Das Problem ist nun das der Arbeitsspeicher verbrauch jede 5 sek. um 12kb ansteigt (laut Windows Taskmgr) Obwohl die Funktion doch den Speicher wieder frei gibt!!! Hab ich was übersehen? Gruß Olli
Delphi-Quellcode:
function print_jobs(printer_index: integer) : integer;
type PJobs = ^TJobs; TJobs = array[0..0]of TJobInfo2; var Needed, JobCounter : DWORD; i : Integer; Device, Driver, Port : array[0..255] of char; hPrinter, hDeviceMode : THandle; Buffer : Pointer; Job : PJobs; const NoJobs = 100; begin //TEIL1 Printer.PrinterIndex := printer_index; Printer.GetPrinter(Device, Driver, Port, hDeviceMode); if WinSpool.OpenPrinter(@Device, hPrinter, nil) then begin EnumJobs(hPrinter, 0, NoJobs, 2, nil, 0, Needed, JobCounter); //GetMem(Buffer, Needed); Buffer := AllocMem(Needed); try Job := Buffer; if EnumJobs(hPrinter, 0, NoJobs, 2, Buffer, Needed, Needed, JobCounter) then begin Form1.LabeledEdit2.Text := IntToStr(JobCounter); if JobCounter > 0 then begin result := 1; end; for i := 0 to JobCounter - 1 do begin if Job[i].pDocument <> nil then Form1.LabeledEdit3.Text := IntToStr(Job[i].TotalPages); end; end; finally FreeMem(Buffer, Needed); end; WinSpool.ClosePrinter(hPrinter); end; sleep(10); end; |
AW: Speicherleck in WinSpool.OpenPrinter API ???
Lade Dir mal die Trial von EurekaLog. (gibt dort auch 2 interessante Demovideos)
FastMM ist zwar auch bei XE dabei, aber EurekaLog ist deutlich komfortabler, finde ich. |
AW: Speicherleck in WinSpool.OpenPrinter API ???
das bringt mich nicht weiter da der Speicher wieder freigegeben wird!
Ich muss wissen warum immer 12kb bei jedem Durchlauf angeforedert wird bzw. nicht richtig freigegeben wird! Eureka gibt mir ne Fehlermeldung aus sobald ich den Speicher nicht freigebe!!! In wieweit kann man denn den Taskmgr von Windows glauben schenken? Gruß |
AW: Speicherleck in WinSpool.OpenPrinter API ???
Ich hab mal deinen Code unter D2009/Win7_64 ausgeführt und habe kein Speicherleck.
Vielleicht ist es woanders? |
AW: Speicherleck in WinSpool.OpenPrinter API ???
Hast du den Code mal von einem Timer alle 5 sekunden ausführen lassen? dann siehst du das im Taskmgr das der Arbeitsspeicher immer 12kb größer wird :cyclops:
|
AW: Speicherleck in WinSpool.OpenPrinter API ???
ich hab ihn jede Sekunden laufen lassen
|
AW: Speicherleck in WinSpool.OpenPrinter API ???
Ggf. müsste man wissen, was die Funktion machen soll und was in printerindex zu übergeben ist (und welche Printer und Jobs vorausgesetzt werden müssen).
Habe mich nicht näher mit dem Auszug beschäftigt, aber ein Testing ist sonst möglicherweise nicht ganz aussagekräftig... |
AW: Speicherleck in WinSpool.OpenPrinter API ???
Printer index ist nur ein Integer wert von 1 bis 6 gibt nur an welcher Printer genommen wird!!!
Die Funktion guckt nur nach ob es für diesen Printer einen aktiven Printjob gibt, wenn ja dann seitenanzahlen anzeigen! Mehr nicht, die anderen funktionen etc. aus dem Prgramm habe ich alle durchgetest daran liegt es nicht, liegt definitiv daran wenn der nach den Drukcern guckt!!! Finde es schon irgendwie komisch!!! |
AW: Speicherleck in WinSpool.OpenPrinter API ???
Mal so ins Blaue geraten: Diese Funktion greift hintenherum auf die verschiedenen Treiber (Drucker, Netzwerk) zu.
Wenn da was faul ist, könnte dich das ganz schön veralbern |
AW: Speicherleck in WinSpool.OpenPrinter API ???
Mir geht es nur darum das ich weiß ob ein druckauftrag aktiv bzw. gesendet worden ist.
Hintergrund dafür ist, dass ich so eine Steckdosenleiste via USB und Netzwerk, schalten kann und somit bei bedarf den Drucker einschalte!!! Deswegen halt auch nen Timer mit 5sek. ! Gibt es sonst eine möglichkeit das der Winspooler eine Message Systemweit schickt und ich diese nur abfangen brauche? Dann kann ich mir den Timer ersparen!! Gruß Olli |
Alle Zeitangaben in WEZ +1. Es ist jetzt 10:00 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz