Sergey Khodych wrote:
>> No, there are 2 separate implementations - one ascii another unicode. During
>> the object creation one would specify either ascii or unicode RIID.
>
> Objects IDirectInputDevice8W and IDirectInputDevice8A has function
> GetProperty. This function get struct of type DIPRO
> No, there are 2 separate implementations - one ascii another unicode. During
> the object creation one would specify either ascii or unicode RIID.
Objects IDirectInputDevice8W and IDirectInputDevice8A has function
GetProperty. This function get struct of type DIPROPSTRING as
input/output parame
Sergey Khodych wrote:
>> In ascii function you are calling unicode function and copying it's output
>> (unicode string) to the ascii string buffer. This is wrong. Also because
>> these functions deal with strings you have to implement both ascii and
>> unicode functions at the same time. You can
> In ascii function you are calling unicode function and copying it's output
> (unicode string) to the ascii string buffer. This is wrong. Also because
> these functions deal with strings you have to implement both ascii and
> unicode functions at the same time. You can't forward one to the othe
Sergey Khodych wrote:
>>> ...
>>> +hr = SysKeyboardWImpl_GetObjectInfo(
>>> (LPDIRECTINPUTDEVICE8W)iface , &didoi,
>>> + ps->diph.dwObj,
>>> ps->diph.dwHow );
>> You mixing unicode and ascii. Also if you are implementing
>> SysK
>
>> ...
>> +hr = SysKeyboardWImpl_GetObjectInfo(
>> (LPDIRECTINPUTDEVICE8W)iface , &didoi,
>> + ps->diph.dwObj,
>> ps->diph.dwHow );
>
> You mixing unicode and ascii. Also if you are implementing
> SysKeyboardAImpl_GetPropert
Sergey Khodych wrote:
>
>
>
>
>
> +static HRESULT WINAPI SysKeyboardAImpl_GetProperty(
> ...
> +if (TRACE_ON(dinput))
> +_dump_DIPROPHEADER(pdiph);
Please drop the TRACE_ON check - it's being done in dump func
