Delphi 10 Seattle wechselt zu Win32 GetPath und redundanten TPoint- und _POINTL-Record-Typen

8

Ich versuche, Code, der in Delphi XE8 funktioniert, nach Delphi 10 Seattle zu portieren. Dieser Code ruft die GetPath-Funktion in Winapi.Windows auf.

Die neue Signatur der Win32-API-Funktion lautet:

%Vor%

In XE8 hatte die Funktion zuvor "var Points, Types", was allgemein als "var untyped" -Parameter bekannt ist.

Das Korrigieren des Codes für die Arbeit mit Delphi 10 Seattle bedeutet "Vereinheitlichung" der willkürlichen Typen im Anwendungscode, um genau die Typen zu verwenden, die in der Einheit selbst deklariert sind. Was mich jedoch verwirrt, ist, dass es zwei Typen gibt, PPointL und TPoint, und wenn ich die GetPath-Funktion zum Laufen bringe, werden die Daten in ein Array von _POINTL-Datensätzen gefüllt, die in Winapi.Windows:

deklariert sind %Vor%

Es gibt jedoch auch einen anderen Typ TPoint, der in System.Types deklariert ist:

%Vor%

Sonst ist FixedInt für 32-Bit- und 64-Bit-Windows Alias ​​für Longint, und daher sind TPoint und _POINTL, soweit ich das beurteilen kann, zumindest auf der Windows-Plattform gleichwertig.

Wenn der Code einer vorhandenen Anwendungskomponente einen Typ namens TPoint verwendet, wie folgt:

%Vor%

... Welchen Sinn habe ich von der Situation vor Ort in den RTL-Quellen in Delphi 10? Was sollte mein Ansatz sein, um dies zu beheben? Alias ​​TPoint zu _POINTL auf Einheitenebene?

Wie behebe ich das Problem und fahre fort? Da dieser Code eine kommerzielle Komponente ist, denke ich, dass ich warten werde, bis der Anbieter das behebt, aber dann denke ich, dass das Verständnis von _POINTL und TPoint in der RTL und warum diese Strukturen in der Definition redundant / dupliziert sind, helfen würde andere portieren Win32-Code niedriger Ebene von Delphi XE8 nach Delphi 10 Seattle.

Update: Als Problemumgehung kann ich einen Import der Funktion GetPath erneut deklarieren und sie als var untypisiert in meinem eigenen Implementierungsbereich importieren lassen und fortfahren:

%Vor%     
Warren P 01.09.2015, 13:37
quelle

1 Antwort

9

Es gibt nicht viel darüber zu sagen, abgesehen von der Tatsache, dass die Änderung zu Winapi.Windows.GetPath in DX Seattle falsch ist. Ich meine, technisch wird es funktionieren, aber es lässt keinen Code, der GetPath in einem isolierten Silo verwendet.

Dieser TPointL Typ ist nicht neu, aber es ist der falsche Typ für GetPath . Die Win32-API-Funktion ist:

%Vor%

Und LPPOINT ist POINT* und POINT entspricht TPoint . Es gibt einige Win32-API-Funktionen, die POINTL verwenden, aber die Mehrheit verwendet POINT . Natürlich hilft Microsoft nicht, indem er zwei identische Typen deklariert, wenn einer ausreicht.

Es ist sehr schwer zu sehen, wie es dem Embarcadero-Entwickler gelungen ist, POINTL in der neuen GetPath zu finden, aber fertig. Aus meiner Sicht sollten Sie einen QP-Bericht einreichen und beantragen, dass die Deklaration von PPointL in PPoint geändert wird.

In der Zwischenzeit wird ein einfacher Cast ausreichen, da diese beiden Typen binärkompatibel sind. Sie möchten ein PPoint übergeben, aber der Compiler möchte PPointL . So übergeben Sie PPointL(...) , wobei ... der Ausdruck ist, der PPoint ergibt.

    
David Heffernan 01.09.2015, 14:38
quelle