string(Integer)

[Uwe Raabe]

Wieso compilierst du überhaupt TPngImage, wo das doch in Vcl.Imaging.pngimage bereits mitgeliefert wird?

[hoika]

Hallo,

Zitat:

da stecken eine Reihe von Komponenten drin

Weil er vielleicht erst mal Compilieren will und dann schrittweise Ersetzen...

[Benmik]

Zitat von Uwe Raabe:

Wieso compilierst du überhaupt TPngImage, wo das doch in Vcl.Imaging.pngimage bereits mitgeliefert wird?

Die Antwort ist natürlich typisch für einen Amateur: Weil ich das Programm seit Jahren entwickle und viel herumexperimentiert habe, so dass offenbar noch irgendwelche Relikte herumliegen, die referenziert werden. Kann aber auch sein, dass ich eine Funktion aus einer Unit benutze, die TPngImage referenziert. Jedenfalls verwende ich gar keine PNG. Natürlich darf ich das nicht (man darf so vieles nicht!), aber ich vertraue darauf, dass der Compiler alles Unbenutzte wegoptimiert.

Ich bin aber recht sicher, dass du die Antworten auf meine Fragen weißt, möchtest du sie nicht geben?

[hoika]

Hallo,
dann benenn doch PngImage.pas um, dann Shift+F9 und schon meldet der Compiler die "verirrte" Unit

Ich dachte, Du benutzt die Unit.
Interessant ist der typecast trotzdem.
aber ich glaube, dass da was Sinnvolles rauskommt

Delphi-Quellcode:

  i:= 100;
  MessageBox(0, PChar(String(i)), '', 0);

Zugriffsverletzung innerhalb der Windows-eigenen Dlls.
Ein harter Typecast mag den Compiler zufriedenstellen, aber ob zur Laufzeit was richtiges rauskommt ...

[Benmik]

Zitat von hoika:

Hallo, dann benenn doch PngImage.pas um, dann Shift+F9 und schon meldet der Compiler die "verirrte" Unit

Wie gedacht, eine andere Komponente, die ich in der Tat benutze, referenziert PngImage.pas.

[hoika]

Hallo,
die Unit ausklammern?

[Benmik]

Die Unit ist ja kein Problem, seit ich die Stelle in LoadFromResourceName(Instance, '#' + IntToStr(ResID)); geändert habe. Da ich nicht mit PNG arbeite, wird die Stelle nie aufgerufen und ich weiß daher nicht, ob mein Ansatz richtig ist.

Ich habe daher aktuell auch kein Problem, ich würde nur gern verstehen und hätte gern eine Antwort auf meine Fragen.

[hoika]

Hallo,
ich würde gern verstehen,
warum der alte Code compiliert werden konnte.

Zitat:

und ich weiß daher nicht, ob mein Ansatz richtig ist

Das ist halt die Frage.

[Uwe Raabe]

Zitat von Benmik:

Ich habe daher aktuell auch kein Problem, ich würde nur gern verstehen und hätte gern eine Antwort auf meine Fragen.

Also: Der Parameter Name von LoadFromResourceName landet am Ende als PChar-Cast bei einem Aufruf von FindResource. In der Beschreibung zu FindResource steht, daß alternativ zu einem Pointer auf einen String auch eine mittels MakeIntResource gewandelte ID eines Resource-Types dort stehen kann. Windows entscheidet das ganz einfach danach, ob der übergebene Pointer in den höheren 16 Bit alles Nullen stehen hat. Da die gültigen Resource-Typen dieses Kriterium per geeigneter Definition erfüllen und String-Pointer eher nicht, stellt das offenbar auch kein Problem dar.

Der Cast string(<Integer>) ist also nur ein syntaktischer Trick für einen Cast PChar(<Integer>), weil der Compiler sonst meckern würde.

Nun kann man unter x86 ja problemlos einen Integer -> Pointer Cast machen, da beide als 32 Bit Wert gespeichert werden. In x64 ist das nicht mehr so. Dort belegen Pointer 64 Bit und ein Cast á la Pointer(<Integer>), PChar(<Integer>) und somit auch string(<Integer>) wird vom Compiler korrekterweise zurückgewiesen.

Übrigens, du solltest die PngImage Unit (und auch die pngzlib, pnglang und das dazugehörige obj-Verzeichnis) tatsächlich einfach löschen (oder wenigstens den Suchpfad darauf entfernen) und die mitgelieferte verwenden. Da du sie ja nicht brauchst, kann dir ja auch nichts passieren, und solltest du sie doch mal brauchen, würde sie vermutlich gar nicht mal funktionieren.