Funktion von PAnsiChar zu PWideChar ändern - wie?

[bjoernga]

Danke für die schnelle Antwort; sie hilft mir aber nicht wirklich weiter. Ich will ja nicht PAnsiChar nach PWideChar kopieren. Außerdem würde das im C++Builder 6 (entspricht etwa Delphi 7 - soweit ich weiß) gar nicht funktionieren, da StrPCopy() PAnsiChar als Parameter erwartet, und ShowMessage() einen AnsiString. Es gilt ja string = AnsiString bei Delphi-Versionen < 2009.

Ich hab wohl die Themen-Überschrift ziemlich unzutreffend formuliert...

Das Problem ist, daß durch die Umstellung der Prozedur auf WideChar die Berechnung von Offset (für die DEVNAMES-Stucktur) nicht mehr stimmt. DEVNAMES erwartet die Anzahl der Zeichen, Offset ist PWideChar, Longint(Offset) - Longint(DevNames) müßte IMHO also zuviel (doppelt soviel) zurückgeben. Deswegen hab ich das ganze durch zwei geteilt. Funktioniert aber nicht.

Oder ist schon die Zuweisung an Offset (die Zeile nach "try") falsch?

Ich komme wie gesagt aus der C++ Ecke und kenne die Feinheiten von Delphi nicht so gut...

Danke schonmal!

[Lyan]

Achso,

hm, debug doch mal und schau in welcher Zeile es genau passiert.
Ansonsten tippe ich einfach mal auf einen Fehler beim allocaten von DevNames.

Also quasi, dass er in der Zeile:

wDriverOffset := (Longint(Offset) - Longint(DevNames)) div 2;

beim Versuch Devnames.wDriverOffset etwas zuzuweisen ne exception wirft?

[baumina]

Verwende statt
sizeof(WideChar) -> length(WideChar)

[DeddyH]

Wieso denn das? Length(WideChar) sollte doch immer 1 ergeben (im Gegensatz zum benötigten Speicher), da könnte man sich die Multiplikation auch sparen.

[baumina]

Ah, falsch gelesen, dachte das SizeOf geht auf das Array of WideChar.

[bjoernga]

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