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/e8cc86b21a1904547df613d892c6a07... 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.