MIDL 2362 and MIDL 2366 warning messages

[Michael Morris]

I received the following warning messages when I attempted to compile a COM
object I have with the new Visual C++ 6.0 compiler and the help doesn't have
a clue what they mean or why I got them. Does anyone have any ideas....

.\TPBtn.idl(135) : warning MIDL2362 : too many methods in the interface,
requires Windows NT 4.0 SP3 or greater : [ Interface 'ITPButton' ]
.\TPBtn.idl(307) : warning MIDL2366 : cannot assign a default value :
vBefore [ Procedure 'Add' ( Interface 'ITPButtonLib' ) ]

(NOTE: Version 5.0 of the compiler DID NOT issue any warning messages.)

[Girish Bharadwaj [mvp]]

Can you post the relevant IDL code bytes? That might help track down the
problem. The first one looks like a problem which might occur when you have
more that 110 methods in dual or a automation interface. SP3 was fixed to
add more than that (1024 if I remember right).
--
Girish Bharadwaj [VC++/MVP].
Dont send email queries to me directly.Please put
them on the newsgroups.
Thank you

Michael Morris wrote in message
<#PbYfPX8...@uppssnewspub05.moswest.msn.net>...

[Michael Morris]

First of all thanks for the response to my query. The following code byte
represents the error MIDL 2366....

[id(7), helpstring("Adds an TPButton object to the list")] HRESULT
Add([in] VARIANT * pVarVal, [in, defaultvalue(0L), optional] VARIANT
vBefore, [in, defaultvalue(0L), optional] VARIANT vAfter);

Once again, this worked perfectly in VC version 5 but causes the warning
below in version 6. Thanks again for all
your assistance...

Michael Morris

Girish Bharadwaj [mvp] wrote in message ...

[Girish Bharadwaj [mvp]]

I think that problem is happening because the datatype for vBefore is not
"typed". i.e. It has to be one of those base types not VARIANT itself. I
dont know why it was working VC 5. Probably it would not have worked had you
specified any other value other than 0.

> [id(7), helpstring("Adds an TPButton object to the list")] HRESULT

>Add([in] VARIANT * pVarVal, [in, defaultvalue(0L), optional] LONG
>vBefore, [in, defaultvalue(0L), optional] LONG vAfter);

should work.

--
Girish Bharadwaj [VC++/MVP].
Dont send email queries to me directly.Please put
them on the newsgroups.
Thank you

Michael Morris wrote in message ...

[Bill Rowe]

I believe Michael is looking for VT_NULL as the 'default value'... or the
pointer to null. I believe there is another workaround (which I will
discover when I need it two weeks from now) to omit the defaultvalue
entirely, although I am not precisely sure what the result is. I got the
clue sometime back that you can evalute the arguments to determine if the
value is 'defaulted' or explicit.

Needless to say, VB has many optional VARIANT arguments to its functions.

Bill

Girish Bharadwaj [mvp] wrote in message

<#G2cwDg8...@uppssnewspub05.moswest.msn.net>...

[Girish Bharadwaj[mvp]]

Of course, optional arguments have to be VARIANTs or variations of
VARIANT*s. But, To supply a defaultvalue to an argument, it has to be
strongly typed so that the typelib marshaller will know how to use that
default value.

--
Girish Bharadwaj [mvp/vc++]

Bill Rowe wrote in message ...
<snip>

[Stefan Cuypers]

Michael, Girish, Bill,

You should not use the defaultvalue and the optional attribute together. The
optional attribute can only be used on variants and it really means that the
parameter is optional. The defaultvalue means the parameter is not optional,
but if it is not specified, a default value is used. The defaultvalue
attribute is mainly used to initialise default variables of base types (such
as int or enum's etc...).

In case of the optional attribute, the Variant will be of type VT_ERROR and
contain the scode DISP_E_PARAMNOTFOUND if the parameter is not specified.
(Check MS knowledgebase article Q153546).

Stefan.

Bill Rowe wrote in message ...

[Girish Bharadwaj [mvp]]

There is nothing wrong with providing defaultvalue and optional together.
Only thing to make sure is that the type of the variable defaultvalue is
applied to, should be one of the oleautomation types. Check out help on
defaultvalue or optional for information about that. Also see MSADO15.idl
file to see a looooot of that kind of usage where they are using optional,
defaultvalue() together. Its not wrong. But, I agree with your logic that
you provide a default because you dont want "nothing" as an argument. But,
Who knows some one might have an application which will treat defaultvalue ,
different from optional tag (a variant with VT_ERROR and
DISP_E_PARAMNOTFOUND).. :-)

--
Girish Bharadwaj [VC++/MVP].
Dont send email queries to me directly.Please put
them on the newsgroups.
Thank you

Stefan Cuypers wrote in message ...

[Bill Rowe]

Girish and Michael,

Oops... I realized my mistake. Yes, it must be explicit (a long, or
VARIANT_BOOL, or whatnot) if you want a default value that is consistent
from container to container (I'm sure some may support variant defaults, but
it isn't spelled out). I guess Michael is looking for a test like...

if ((OptArg.vt == VT_ERROR) && (OptArg.scode == DISP_E_PARAMNOTFOUND))
......

this should be the result of the [optional] VARIANT param being omitted.
BTW - the docs are very fuzzy, optional states that it must be a VARIANT or
*VARIANT, and defaultvalue suggests that the value must be 'able to be'
represented as a VARIANT. This is pretty stock though, and the above test
IS a very clear implemenation.

Bill

Girish Bharadwaj[mvp] wrote in message

<6vi219$ksh$1...@wbnws01.ne.highway1.com>...

>Of course, optional arguments have to be VARIANTs or variations of
>VARIANT*s. But, To supply a defaultvalue to an argument, it has to be
>strongly typed so that the typelib marshaller will know how to use that
>default value.
>
>--
>Girish Bharadwaj [mvp/vc++]
>

>Bill Rowe wrote in message ...

><snip>
>
>
>