Direct2D Anwendung

[pcoder]

@Kas Ob.
Also nur eine Pascal declaration order (VTable) kann korrekt funktionieren, aber welche?
Für IDWriteFontSet1 gibt es nun noch eine weitere Variante hier

Delphi-Quellcode:

    function GetFilteredFonts(const {count: indexCount} indices: PUInt32; indexCount: UInt32; out {COM out pointer} filteredFontSet: IDWriteFontSet1): HRESULT; stdcall; overload;
    function GetFilteredFonts(const {count: fontAxisRangeCount} fontAxisRanges: PDWRITE_FONT_AXIS_RANGE; fontAxisRangeCount: UInt32; selectAnyRange: BOOL; out {COM out pointer} filteredFontSet: IDWriteFontSet1): HRESULT; stdcall; overload;
    function GetFilteredFonts(const {count: propertyCount} properties: PDWRITE_FONT_PROPERTY; propertyCount: UInt32; selectAnyProperty: BOOL; out {COM out pointer} filteredFontSet: IDWriteFontSet1): HRESULT; stdcall; overload;

[gubbe]

Zitat:

Zitat von pcoder (Beitrag 1549428)

Für IDWriteFontSet1 gibt es nun noch eine weitere Variante hier

Das wird automatisch generiert aus den Windows Metadata (winmd) Informationen von Microsoft. Gibt es auch von Embarcadero, wie ich schon weiter oben schrieb über GetIt (Windows API from WinMD).
Eigentlich sollte ja hier die Reihenfolge stimmen. Warum weicht das trotzdem ab von der hier im Thread als korrekt angegebenen Variante?

[pcoder]

Offenbar gibt es hier im Forum keinen offiziellen Delphi Support. Etwas überraschend,
wenn man bedenkt daß die Verwendung von COM interfaces eine sehr grundlegende Sache ist.
Und WindowsAPIfromWinMD (via GetIt) ist nicht vorhanden in Delphi CE12.1.

[gubbe]

Zitat:

Zitat von pcoder (Beitrag 1549430)

Offenbar gibt es hier im Forum keinen offiziellen Delphi Support. Etwas überraschend,
wenn man bedenkt daß die Verwendung von COM interfaces eine sehr grundlegende Sache ist.
Und WindowsAPIfromWinMD (via GetIt) ist nicht vorhanden in Delphi CE12.1.

Was erwartest Du hier? Offiziellen Delphi-Support in einem Community-Forum?

Ok, wenn es das Paket nicht bei GetIt für die Community-Edition gibt (warum auch immer), hast Du ja eine Alternative gefunden.

[pcoder]

Ich erwarte korrekte Interface-Deklarationen für Alle Delphi Nutzer. Punkt!

[Kas Ob.]

Zitat:

Zitat von pcoder (Beitrag 1549428)

@Kas Ob.
Also nur eine Pascal declaration order (VTable) kann korrekt funktionieren, aber welche?
Für IDWriteFontSet1 gibt es nun noch eine weitere Variante hier

Delphi-Quellcode:

    function GetFilteredFonts(const {count: indexCount} indices: PUInt32; indexCount: UInt32; out {COM out pointer} filteredFontSet: IDWriteFontSet1): HRESULT; stdcall; overload;
    function GetFilteredFonts(const {count: fontAxisRangeCount} fontAxisRanges: PDWRITE_FONT_AXIS_RANGE; fontAxisRangeCount: UInt32; selectAnyRange: BOOL; out {COM out pointer} filteredFontSet: IDWriteFontSet1): HRESULT; stdcall; overload;
    function GetFilteredFonts(const {count: propertyCount} properties: PDWRITE_FONT_PROPERTY; propertyCount: UInt32; selectAnyProperty: BOOL; out {COM out pointer} filteredFontSet: IDWriteFontSet1): HRESULT; stdcall; overload;

Strangely enough it seems Rust guys ditched this IDWriteFontSet1 altogether :o

I am not sure what exactly is your question, so sorry, but if you asking about the correctness of the implementation and VTable layout, then using the header file lets say from https://github.com/apitrace/dxsdk/bl....h#L3053-L3099 will be correct as long as you are using Visual Studio compiler, but as i listed few example earlier and how even Rust struggling to fix this mess, as suggested a correct layout and re-ordering of these overloaded interface methods that will fic this once and for all.
And the correct order for Pascal/Delphi and Rust and any other compiler or language (as long it will not act like VS compiler and switch order) should be as posted before this one :

Delphi-Quellcode:

    function GetFilteredFonts(indices: UINT32;
                              indexCount: UINT32;
                              out filteredFontSet: IDWriteFontSet1): HResult; overload; stdcall;

    function GetFilteredFonts(properties: PDWRITE_FONT_PROPERTY;
                              propertyCount: UINT32;
                              selectAnyProperty: BOOL;
                              out filteredFontSet: IDWriteFontSet1): HResult; overload; stdcall;

    function GetFilteredFonts(fontAxisRanges: DWRITE_FONT_AXIS_RANGE;
                              fontAxisRangeCount: UINT32;
                              selectAnyRange: BOOL;
                              out filteredFontSet: IDWriteFontSet1): HResult; overload; stdcall;

Simply order-reverse overloaded methods at first occurrence, of course if they are scattered between other methods then group them at first occurrence.

The header mentioned at https://www.winsoft.sk/win32api.htm is wrong and doesn't comply with Windows SDK, so i will assume someone might tried one function and only fixed it by shuffling them and didn't try the others, or just gave up, the order is wrong and look like this

Delphi-Quellcode:

    procedure GetFilteredFonts(const {count: indexCount} indices: PUInt32; indexCount: UInt32; out {COM out pointer} filteredFontSet: IDWriteFontSet1); safecall; overload;
    procedure GetFilteredFonts(const {count: fontAxisRangeCount} fontAxisRanges: PDWRITE_FONT_AXIS_RANGE; fontAxisRangeCount: UInt32; selectAnyRange: BOOL; out {COM out pointer} filteredFontSet: IDWriteFontSet1); safecall; overload;
    procedure GetFilteredFonts(const {count: propertyCount} properties: PDWRITE_FONT_PROPERTY; propertyCount: UInt32; selectAnyProperty: BOOL; out {COM out pointer} filteredFontSet: IDWriteFontSet1); safecall; overload;

[TiGü]

I think the problem with the MfPack translations is that at some point they took the order from the MSDN website (or auto-generated documentation) instead of using the real header files from the Windows SDK one-to-one.

[Kas Ob.]

Zitat:

Zitat von TiGü (Beitrag 1549441)

I think the problem with the MfPack translations is that at some point they took the order from the MSDN website (or auto-generated documentation) instead of using the real header files from the Windows SDK one-to-one.

No, the problem is not that, Windows SDK header and the documentation are correct and identical, the problem exist in Microsoft compiler and undocumented behaviour, this is what cause this mess, the compiler rearrange VTable layout at its own, hence producing its own layout that will work and always work with the same headers, the problem is different compilers will follow strict layout and this layout doesn't with the binary produced by lets say VS compiler, but all these headers belong to Windows components that produced by that quirky compiler and hence all other compilers need to adjust their own header to make their own binary compatible with these shipped with/for Windows, in this case Media Foundation and DirectX ( yes Direct3d and DirectDraw both suffer from this very strange binary when it comes to overloaded interface methods)

[pcoder]

Zitat:

Zitat von TiGü (Beitrag 1549441)

using the real header files from the Windows SDK one-to-one.

Im SDK header (.h) file gibt es keine Beschreibung der ABI-Reihenfolge, kann deshalb nicht! verwendet werden.

[TiGü]

Ach du Scheiße, es stimmt. :shock:
Dann ist ja auch gar nichts Verlass und der Aufruf von COM-Interfaces vom Windows Betriebssystem Komponenten mit überladenen Methoden ist mehr oder weniger zufällig:

https://learn.microsoft.com/en-us/an...svgelement-api
https://github.com/FactoryXCode/MfPack/issues/4
https://github.com/microsoft/win32metadata/issues/600 (check kennykerrs Antwort)
https://github.com/microsoft/win32metadata/issues/815
https://stackoverflow.com/questions/...-the-same-name