Ich habe diese Funktion editiert da sie mit PWCHAR nicht mit meinem Wrapper kompatible ist.
Und nein es gibt keine Problem sonst hätte mir GdipCheck das schon gemeldet.
Ich verwende nix von progdigy sondern habe meine eigene
Unit erstellt auf der Basis von Win32Api.
Delphi hat die Eigenschaft alles unnötig aufzubauschen.
Sieht man ja an den Kompilaten
Du wirst schon wissen was du tust, aber wäre es nicht sinnvoller gewesen deinen Wrapper entsprechend anzupassen, anstatt die Übersetzung der
DLL-Funktion?
Schau mal hier, wie die Jungs vom Wine-Projekt das gelöst haben:
https://source.winehq.org/WineAPI/Gd...yFromName.html
Du bist ja nun inzwischen etwas sattelfester in C/C++.
Was für ein Typ hat das erste Argument?
mag ja sein das ich ein zwei Sachen nicht initialisiert habe.. meine Regel ist solange der Compiler nicht meckert kompiliert
und alles rund läuft sollte das schon gut sein.
Auch wenn wir uns sowas alle wünschen würden, aber der Compiler ist da etwas schludderig und keine Hilfe.
Kann es sein, dass bei dir strFormat, boundingBox und layoutRect globale Variablen sind?
Die fehlen schlicht und ergreifend in der Funktion und deswegen kann es nicht kompilieren.
Wenn ich das nun einfüge und die beiden Rechtecke nicht per FillChar (oder ZeroMemory) initialisiere, haben die zufällige Werte und werden von GdipMeasureString nicht richtig ausgefüllt bzw. falsch übernommen.
Das knallt dann spätestens beim berechnen von bH oder bW, weil Round einen "invalid floting point operation"-Fehler wirft.