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

Mon Nov 29 22:38:48 CST 2021

Thank you both for the feedback. And thank you Connor for the detailed
explanation, you've been very helpful. :)

On Mon, Nov 29, 2021 at 10:19 PM Connor McAdams <conmanx360 at gmail.com>
wrote:

> 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 at 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 at 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 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.
> >> >>>
> >> >>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20211129/08b8d843/attachment.htm>