WCHAR matriz no están adecuadamente formados

Question

Tengo una interfaz de COM con un método siguiente definición (IDL notación):

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

Biblioteca de tipos de cálculo se utiliza para COM+, el tipo de biblioteca que está inscrita, otros métodos de la interfaz de trabajo bien cuando se llama a través de COM+, pero no de este método.

El lado del servidor de copias de una matriz de WCHARs en el awcBuffer y su longitud en pwcBuffer, no hay un desbordamiento de búfer que alguna vez ocurre.

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;
}

Cuando el cliente llama a este método, a través de COM+ el contenido del buffer se pierde.Específicamente sólo el primer gran char se conserva - si el servidor de copias de "Ejemplo" de ancho de cadena de caracteres, el cliente sólo recibe "S" de la cadena.El valor de retorno en el tamaño del cliente es S_OK, la longitud de búfer que se devuelve al cliente es exactamente la misma que la del servidor de copia.

Finalmente me cambié a BSTR para solucionar este problema, pero es realmente interesante ¿por qué todo válido en busca construir no funciona.

¿Cuál es la posible razón de que el comportamiento descrito?

Answer 1

IIRC, el contador de referencias de biblioteca de tipos ignora el atributo size_is - por lo tanto, sólo el 1 Char se calculan referencias

.

Answer 2

J. Que pasa es correcto. Para el contador de referencias de biblioteca de tipos al trabajo, la interfaz COM debe ser compatible con OLE Automation. El contador de referencias de biblioteca de tipos se implementa en oleaut32.dll, así que supongo que hay una idea en el nombre.

[size_is] es perfectamente válido IDL, y compila en una biblioteca de tipos válidos, pero el contador de referencias de biblioteca de tipos puede manejar solamente un subconjunto de interfaces válidas. Ese subconjunto que normalmente se conoce como la automatización OLE. Como acotación al margen, los clientes de Visual Basic 6 sólo puede hablar de automatización, por lo que no sería capaz de consumir su interfaz sea.

Trate de marcar su interfaz con el atributo [oleautomation] en su IDL. Se le debe dar un mensaje de advertencia o de error que podría apuntar a una mayor información sobre el tema.

En COM "normal", se podría generar un proxy / stub DLL de su IDL para hacer el cálculo de referencias, pero me temo que no recuerdo si COM + usaría su código de clasificación personalizado aunque la molestia de construirlo .

Actualización: en el libro "COM y .NET Servicios de componentes" de Juval Lowy, me encontré con esta declaración: " ... componentes configurados no pueden utilizar las interfaces que requieren el cálculo personalizado ". Así que supongo que la interfaz no va a funcionar en COM +. Si es posible, volver a escribir para usar un BSTR en su lugar.

Answer 3

Un par de preguntas:

• ¿Por qué no está usando BSTR?
• ¿Tiene las fuentes de la GetText función?
• ¿Cuál es el tamaño del búfer devuelto por la función?