The 'xxx' on that wiki page is referring to the function name and
argument types, not the names of the arguments: "naming all API
functions and types".

Typically, we rename function arguments, getting rid of camelcase, i.e
'oldValue' can become 'old' or 'old_value'. Usually you can tell by
looking at other function prototypes within the same header.

PROPERTYIDs are int, as found in include/uiautomationclient.idl:
'typedef int PROPERTYID;', so a signed integer in the FIXME is
probably correct. In the future, you can typically find a definition
by using grep in the source code, but that's beyond what I can explain
here :)

On Mon, Nov 29, 2021 at 10:00 PM Mohamad Al-Jaf <mohamadaljaf@gmail.com> wrote:
>
> Hi Connor,
>
> Oh, I see. Setting the spec file parameter as int128 fixes the issue. Thank you for that.
>
> I thought that Wine only accepted str, wstr, ptr, and long. I was following this guide: https://wiki.winehq.org/Developer_Hints#Implementing_new_API_calls
>
> Regarding the naming convention, I see that the Proton Experimental stub uses the names old and new instead of oldValue and newValue. The Developer Hints page in the Wine wiki says to use the same name as Windows, i.e. 'xxx'. But I see a lot of functions in Wine use shortened variable names. I'm not sure how to name the variables. Are oldValue and newValue acceptable?
>
> Also, for the FIXME channel they specify the PROPERTYID as an unsigned decimal integer. I originally specified it as a signed decimal integer. The MSDN page makes no mention of whether it is signed or unsigned, how can I find out which to use in the future?
>
> On Mon, Nov 29, 2021 at 8:45 PM Connor McAdams <conmanx360@gmail.com> wrote:
>>
>> 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@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@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@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@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.
>> >>>
>> >>