[PATCH 4/4] uiautomationcore: Add UiaRaiseAutomationPropertyChangedEvent stub.

[Connor McAdams]

Yeah, the arguments are not pointers, they are VARIANTs passed by
value, not reference. See
https://github.com/ValveSoftware/wine/commit/e8cc86b21a1904547df613d892c6a076703038dc#diff-6843aef766f8136d8d97cc6eb9a143901efaccae8ff4c49c414e133856c650ca
for Proton Experimental's stub.

They should be int128's, because that is the size of the VARIANT structure.

On Mon, Nov 29, 2021 at 8:06 PM Mohamad Al-Jaf <mohamadaljaf at gmail.com> wrote:
>
> Sorry, my mistake, forgot to reply-all.
>
> If the original code is used, the binary uiautomationcore.dll fails to compile in the 32-bit build of Wine. The 64-bit build of Wine compiles successfully. Here is the error log:
>
> /usr/lib/gcc/i686-w64-mingw32/11.2.0/../../../../i686-w64-mingw32/bin/ld: uiautomationcore.dll-61a5829a.spec.o:fake:(.edata+0x170): undefined reference to `UiaRaiseAutomationPropertyChangedEvent at 16'
> collect2: error: ld returned 1 exit status
> winegcc: /usr/bin/i686-w64-mingw32-gcc failed
> make[1]: *** [Makefile:215741: dlls/uiautomationcore/uiautomationcore.dll] Error 2
>
> I can submit the original code with the correct prototype but I can't build the 32-bit version of Wine on my machine. Perhaps there's something wrong with my machine? I don't know why the error is happening.
>
> Here is the line in the spec file of the original code:
>
> @ stdcall UiaRaiseAutomationPropertyChangedEvent(ptr long long long)
>
> On Mon, Nov 29, 2021 at 4:41 AM Nikolay Sivov <nsivov at codeweavers.com> wrote:
>>
>> On 11/29/21 12:18 PM, Mohamad Al-Jaf wrote:
>>
>> Hi Nikolay,
>>
>>
>> Please reply-all next time to include the list.
>>
>>
>> I see, that would explain why it fails to compile in 32-bit Wine. But how does it compile on the 64-bit version? It worked just fine and the FIXME channel displayed the correct debugstr_variant output.
>>
>> This was the original code:
>>
>> HRESULT WINAPI UiaRaiseAutomationPropertyChangedEvent(IRawElementProviderSimple *provider, PROPERTYID id, VARIANT oldValue, VARIANT newValue)
>> {
>>     FIXME("(%p, %d, %s, %s): stub\n", provider, id, debugstr_variant(&oldValue), debugstr_variant(&newValue));
>>     return S_OK;
>> }
>>
>> HRESULT WINAPI UiaRaiseAutomationPropertyChangedEvent(IRawElementProviderSimple *provider, PROPERTYID id, VARIANT oldValue, VARIANT newValue);
>>
>> I'm not sure I understand how the prototype is wrong, can you please explain it to me?
>>
>>
>> What doesn't compile? Prototype has to match the one used on Windows, you can't change that for exported functions.
>>
>>
>> For stubs, I thought they were unimplemented functions that simply returned either a boolean or a single value. So in this case, would it be an implementation? I'm not sure what to put in the subject line. The function above it, UiaRaiseAutomationEvent, also returns a value, the same one. Sorry, I'm just trying to understand you and learn more.
>>
>>
>> Connor has been working on this lately, I'll leave it to him to comment.
>>
>>
>> On Mon, Nov 29, 2021 at 3:09 AM Nikolay Sivov <nsivov at codeweavers.com> wrote:
>>>
>>>
>>>
>>> On 11/29/21 10:35 AM, Mohamad Al-Jaf wrote:
>>> > +/***********************************************************************
>>> > + *          UiaRaiseAutomationPropertyChangedEvent (uiautomationcore.@)
>>> > + */
>>> > +HRESULT WINAPI UiaRaiseAutomationPropertyChangedEvent(IRawElementProviderSimple *provider, PROPERTYID id, VARIANT *oldValue, VARIANT *newValue)
>>> > +{
>>> > +    FIXME("(%p, %d, %p, %p): stub\n", provider, id, oldValue, newValue);
>>> > +    return S_OK;
>>> > +}
>>> The prototype is wrong, and return value is not what stubs usually have.
>>>
>>