Warning MIDL1015: /W0 or /no_warn overrides warning-level switch
/W0 or /no_warn overrides warning-level switch
The W0 or no_warn option has been specified along with the warning-level switch W1, W2, or W3. The /no_warn switch takes precedence over all other warning-level switches.
The final warnings in the IDL file have been addressed. Two cases have been handled by disabling the warnings.
In methods SelectShapes and GenerateContour, the ‘optional’ attribute was added to what are otherwise required parameters, only because they followed other optional parameters (since non-optional parameters may not follow optional parameters).
In method CreateTinFromPoints, a SAFEARRAY of pointers to interfaces is specified, with the warning that it will not work. Not knowing the history of this function, or if it is in use, it was determined to allow the warning in this case.
So as not to change the existing interface, we have disabled the warning just for these functions, while any future functions that would generate the warnings should be disallowed, and addressed properly.
Submitted first round of changes.
Changed MIDL Compiler Warning Level to 3, to match that of the c++ compiler. This removed the original warning (Warning MIDL1015), and now we’ll see the remaining warnings.
Modified most combinations of [optional] and [defaultvalue], generally removing the [optional] and verifying the proper [defaultvalue].
Changed default values for VARIANT_BOOL to 0 (for VARIANT_FALSE) and -1 (for VARIANT_TRUE), since the compiler would not accept the defined values for VARIANT_TRUE and VARIANT_FALSE, and some of the existing defaults (e.g. setting to TRUE, which equals 1 rather than -1) were not all appropriate.
Modified the definitions of the Map.GlobalSettings and Map.Extents properties, since their definitions were not properly using their ID’s, which resulted in not always being accessible as late-bound properties.
I agree, we should not hide warnings but resolve them.
Please continue with your work. It is OK if it takes a bit of time. I plan to publish a new release end August / early September. It would be great if we have solved all warnings by then.
Ok. As it is, many of these changes were just a matter of search/replace. So, working on a local copy, I’ve reduced the warnings to less than 20. I will run with this for a little while before checking anything back in, just to get a sense of stability and reliability.
Just a follow-up on the MIDL warnings we are getting (if we set the MIDL warning level to 3).
So we get about 580 warnings. It looks like they’re all related to the various combinations of [optional] and [defaultvalue()]. [defaultvalue] already implies optional, by the common understanding of an optional parameter. In a high-level language, we commonly define an optional parameter by providing a default value, to be used if the caller does not provide that parameter.
However, in MIDL, an [optional] does not require a default value, and if the parameter is not provided, it is considered EMPTY (and in fact, would be assigned to the VARIANT VT_EMPTY value). Some COM-aware languages can test for an EMPTY parameter, and respond accordingly. As such, many of the warnings we are getting are because an [optional] parameter is required to be a VARIANT, but in most of our cases, it is not a VARIANT.
So the first step would be to remove the [optional] attribute from every call in which we also provide a [defaultvalueI()], since that was really our intent. This reduces the warnings down to 144.
Many of these warnings are in reference to the optional ICallback pointer. We have declared this as [optional], but it is not a VARIANT, and hence the warning. However, we don’t really mean for this to be [optional] in the MIDL sense of the word, but instead should declare it as [defaultvalue(NULL)], since that is our intent, and we test for NULL within the called procedures.
Changing these and other similar pointer-based parameters (defaulting to NULL), leaves about 44 warnings, which at this point require individual review. I don’t think they’re difficult, they just need to be reviewed.
I’m not suggesting we change this immediately, since it seems that we’re not in a broken state. But I do think that at some point we should take the time to clean these up. I think the compiler is covering for us, processing these warnings by applying some default handling. But ultimately, we should not rely on the default behavior, but should instead take deliberate control of the functional definitions.
I’m sure we all agree. It’s just a matter of when to make the change. I don’t mind making the changes, but I’m not always reliable in the short term. Perhaps I could just start down the path, making the changes more gradually.