WCHAR Array nicht richtig vermarshallten

Question

Ich habe eine COM-Schnittstelle mit einer folgenden Methodendefinition (IDL-Notation):

SCODE GetText( [in, out] ULONG* pcwcBuffer,
              [out, size_is(*pcwcBuffer)] WCHAR* awcBuffer );

Typelib-Marshalling für COM + verwendet wird, wird die Typenbibliothek registriert, andere Methoden der Schnittstelle Arbeit allright, wenn sie durch COM + genannt, aber diese Methode nicht.

Die Server-Seite kopiert ein Array von WCHARs in die awcBuffer und seine Länge in pwcBuffer, overrun kein Puffer jemals auftritt.

static const wchar_t* Text = L"Sample";
STDMETHODIMP CImpl::GetText( ULONG* bufferLength, WCHAR* buffer )
{
    const int length = wcslen( Text );
    *bufferLength = length;
    memcpy( buffer, Text, length * sizeof( WCHAR ) );
    return S_OK;
}

Wenn der Client diese Methode durch COM ruft + den Pufferinhalt verloren geht. Insbesondere wird nur die ersten breiten Zeichen erhalten bleiben - wenn der Server kopiert „Sample“ wide Zeichenkette, nur der Client „S“ string empfängt. Der Rückgabewert auf der Client-Größe ist S_OK, die Pufferlänge an den Client zurückgegeben wird genau das gleiche wie das, was der Server kopiert.

Ich wechselte schließlich bstr dieses Problem zu umgehen, aber es ist wirklich interessant, warum das ganze gültig sucht Konstrukt funktioniert nicht.

Was ist der mögliche Grund des beschriebenen Verhaltens?

Answer 1

IIRC, ignoriert das typelib Einweiser das size_is Attribut - also nur 1 Zeichen gemarshallte ist

.

Answer 2

J. Passing ist richtig. Für den typelib Einweiser zu arbeiten, muß der COM-Schnittstelle OLE-Automatisierung kompatibel sein. Die typelib Einweiser in oleaut32.dll implementiert, so dass ich denke, es gibt einen Hinweis auf den Namen.

[size_is] ist absolut gültige IDL und kompiliert in eine gültige typelib, aber die typelib Marshaler kann nur eine Teilmenge der gültigen Schnittstellen handhaben. Das Teilmenge wird in der Regel als OLE-Automation bezeichnet. Als Nebenwirkung kann VB6-Clients OLE-Automatisierung nur sprechen, so würden sie nicht in der Lage sein, Ihre Schnittstelle entweder zu konsumieren.

Versuchen Sie, Ihre Schnittstelle mit dem [Oleautomation] Attribut in Ihrer IDL-Kennzeichnung. Es sollte Ihnen eine Warnung oder eine Fehlermeldung, die Sie, um weitere Informationen zu diesem Thema verweisen könnten.

In „normalen“ COM, könnten Sie einen Proxy / Stub-DLL aus Ihrer IDL erzeugen, um die Rangierung zu tun, aber ich fürchte, ich kann mich nicht erinnern, ob COM + Ihren benutzerdefinierten Rangier-Code selbst verwenden würde, wenn Sie die Mühe gemacht, es zu bauen .

Update: in Juval Löwy Buch "COM und .NET Component Services", ich diese Aussage gefunden: " ... konfiguriert Komponenten können nicht-Schnittstellen verwenden, die benutzerdefinierte Marshalling benötigen ". Also ich denke, dass Schnittstelle nie in COM + arbeiten. Wenn Sie können, neu schreiben, anstatt eine BSTR zu verwenden.

Answer 3

Ein paar Fragen:

• Warum bist du nicht mit BSTR?
• Haben Sie die Quellen der GetText Funktion haben?
• Was ist die Größe des Puffers von der Funktion zurückgegeben?