Ich bin mir inzwischen gar nicht mehr sicher, ob der Fehler wirklich in der obigen Prozedur (#1) liegt. Weil: wenn ich die Zeilen zwischen
Delphi-Quellcode:
with DevNames^ do
begin
// wDriverOffset := (Longint(Offset) - Longint(DevNames)) div 2;
// usw ...
end;
auskommentiere, tritt der Fehler nicht auf. In der aufrufenden Funktion sieht das so aus:
Delphi-Quellcode:
function TPrinterSetupDialogW.Execute: Boolean;
var
PrintDlgRec: TPrintDlgW;
DevHandle: THandle;
begin
FillChar(PrintDlgRec, SizeOf(PrintDlgRec), 0);
with PrintDlgRec do
begin
lStructSize := SizeOf(PrintDlgRec);
hInstance := SysInit.HInstance;
GetPrinter(DevHandle, hDevNames); // <- Prozedur aus #1
hDevMode := CopyData(DevHandle);
Flags := PD_ENABLESETUPHOOK or PD_PRINTSETUP;
lpfnSetupHook := DialogHook;
hWndOwner := Application.Handle;
Result := TaskModalDialog(@PrintDlgW, PrintDlgRec); // <- Es knallt, wenn diese Funktion zurückkommt
if Result then
SetPrinter(hDevMode, hDevNames)
else begin
if hDevMode <> 0 then GlobalFree(hDevMode);
if hDevNames <> 0 then GlobalFree(hDevNames);
end;
end Ich
end;
Wenn ich mit F7/F8 durch den Code marschiere, gibts keine
Exception, stattdessen ploppt das CPU-Fenster immer nach Result := TaskModalDialog() auf. Ich hab das mal als Screenshot angehängt, falls sich da jemand auskennt - für mich könnt da genausogut chinesisch drinstehen...
Möglicherweise kollidiert da irgendwas in den Tiefen der
Ansi-
VCL mit den Tnt-Controls: in TntForms und auch in TntDialogs werden ja die Windows Messages ganz schön umgebogen. Und der TPrinterSetupDialog klopft da ein
Ansi-gekapseltes Fenster dazwischen - könnts das sein? (Oder andersrum: kann das gut gehen?)
Ich werd das ganze wohl anders angehen: aus C++ heraus direkt die Win-
API-Funktion PrintDlgW() aufrufen, dann hätt ich mich am Problem vorbeigemogelt...
Falls aber doch noch jemand die Lösung findet, hätt ich natürlich nichts dagegen
