Francois Gouget fgouget@free.fr writes:
@@ -537,7 +547,7 @@ int EnumFuncs(ITypeInfo *pTypeInfo, int } bFirst = TRUE; #define ENUM_PARAM_FLAG(x)\
if(pFuncDesc->lprgelemdescParam[j].paramdesc.wParamFlags & x)\
if(((myELEMDESC*)&(pFuncDesc->lprgelemdescParam[j]))->u.paramdesc.wParamFlags & x) \ {\
Why can't you use U(x) instead?
On Fri, 20 Oct 2006, Alexandre Julliard wrote:
Francois Gouget fgouget@free.fr writes:
@@ -537,7 +547,7 @@ int EnumFuncs(ITypeInfo *pTypeInfo, int } bFirst = TRUE; #define ENUM_PARAM_FLAG(x)\
if(pFuncDesc->lprgelemdescParam[j].paramdesc.wParamFlags & x)\
if(((myELEMDESC*)&(pFuncDesc->lprgelemdescParam[j]))->u.paramdesc.wParamFlags & x) \ {\
Why can't you use U(x) instead?
My basic assumption is that we want to be able to compile oleview on Windows. But then I had in mind that this was a conformance test so I was pretty confused. Still it seems like cmopiling our programs on Windows should be feasible.
So I modeled my approach on what I remembered of an old commit to dlls/user/tests/input.c (and menu.c) which had the same issue with the INPUT type.
The PSDK uses a nameless union whether NONAMELESSUNION is defined or not. But if we assume that NONAMELESSUNION will never be defined when we compile with the PSDK headers, then we can use U(x).
Francois Gouget fgouget@free.fr writes:
The PSDK uses a nameless union whether NONAMELESSUNION is defined or not. But if we assume that NONAMELESSUNION will never be defined when we compile with the PSDK headers, then we can use U(x).
That's what the rest of the oleview code already does, so it should be OK.