Interop and not passing optional out params

[spammy]

Hi all,

Im attempting to use a COM class in C# via .NET interop. The class has two
modes - synhrounous and asynchronous. The mode is determined by the use (or
not) of an optional out parameter:

COMClass test = new COMClass();

object results = null;

test.DoWork(arg1, arg2, out results); //synchronous call - results are in
results after execution.

test.AsyncReturn += eventhandler;

test.DoWork(arg1, arg2, out null); //asynchronous call - fires
test.AsyncReturn.

Im sure you can see the problem here - the third out argument cannot be
null. Neither can Type.Missing or Reflection.Missing.Value - these are both
readonly fields. Omitting the out results in a type error. If I try:

object results = Type.Missing;

test.DoWork(arg1, arg2, out results);

then the call is synchonous, no calls are made to the eventhandler and there
is data in results after the call. Is there any way of specifying an
optional out parameter as not being there?

Thanks in advance!

Spammy

[Jon Skeet [C# MVP]]

spammy <[e-mail]> wrote:

Im attempting to use a COM class in C# via .NET interop. The class has two
modes - synhrounous and asynchronous. The mode is determined by the use (or
not) of an optional out parameter:

Hmm. This is odd - one of the things about an "out" parameter is that
it doesn't need to be definitely assigned before use - in other words,
the initial vaule shouldn't matter.

Perhaps it should be a ref parameter instead of out?

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[spammy]

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...

spammy <[e-mail]> wrote:

Im attempting to use a COM class in C# via .NET interop. The class has two modes - synhrounous and asynchronous. The mode is determined by the use (or not) of an optional out parameter:

Hmm. This is odd - one of the things about an "out" parameter is that
it doesn't need to be definitely assigned before use - in other words,
the initial vaule shouldn't matter.

Perhaps it should be a ref parameter instead of out?

The direction itself was decided when I added the COM as a reference. To be
clear, I can pass an unintialised object to the function too:

object results;
test.DoWork(arg1, arg2, out results); //synchronous call

and it would work. Basically the old value of results (even if that happens
to be a reference to Missing) are overwritten by DoWork. I need to
explicitly leave it out rather than leave a placeholder - Can I possibly add
a new method to the COM skeleton interop wrapper leaving out the optional
parameter?

Alternatively I read that I actually need the runtime to pass a variant of
type VT_ERROR, set to DISP_E_PARAMNOTFOUND. Is it possible for me to do this
manually?

Spammy

[Jon Skeet [C# MVP]]

spammy <[e-mail]> wrote:

The direction itself was decided when I added the COM as a reference. To be
clear, I can pass an unintialised object to the function too:

object results;
test.DoWork(arg1, arg2, out results); //synchronous call
Indeed.
and it would work. Basically the old value of results (even if that happens
to be a reference to Missing) are overwritten by DoWork.
Yes - they have to be.
I need to explicitly leave it out rather than leave a placeholder - Can I
possibly add a new method to the COM skeleton interop wrapper leaving out
the optional parameter?
I don't know, to be honest.
Alternatively I read that I actually need the runtime to pass a variant of
type VT_ERROR, set to DISP_E_PARAMNOTFOUND. Is it possible for me to do this
manually?

If you're passing information in which ends up being read, it shouldn't
be an out parameter.

I suggest you make it *not* be an out parameter, and *not* an optional
parameter either.

Out parameters are for values which aren't read in the called method -
they're only written. Optional parameters just aren't supported in C#.
How those two facets interact with COM, I don't know (and you should
possibly ask on the .interop group) but those are the two important
things from the C# side.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[spammy]

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...

Alternatively I read that I actually need the runtime to pass a variant of type VT_ERROR, set to DISP_E_PARAMNOTFOUND. Is it possible for me to do this manually?
If you're passing information in which ends up being read, it shouldn't
be an out parameter.

Im not sure whether it is being read or not being read - I suspect its the
presence of the variable itself along with it being an out parameter that is
tripping up the marshalling somehow, and not providing it as a variant
VT_ERROR etc.
I suggest you make it *not* be an out parameter, and *not* an optional
parameter either.
Again, its not me thats doing it. Although I am currently looking at the
disassembled interop assembly to see if i can override the automated out
param and change it to an in one.
Out parameters are for values which aren't read in the called method -
they're only written. Optional parameters just aren't supported in C#.
How those two facets interact with COM, I don't know (and you should
possibly ask on the .interop group) but those are the two important
things from the C# side.

Interop group? Doh, Im on my way, thanks!

Spammy

[Cor Ligthert]

Hi Jon,

Is it not better to give the advice direct to ask this question in the
Interop group when you are not sure that you can answer this question?

Cor

[Jon Skeet [C# MVP]]

Cor Ligthert <no**********@planet.nl> wrote:

Is it not better to give the advice direct to ask this question in the
Interop group when you are not sure that you can answer this question?

I've answered the C# side as well as I can, and already suggested that
he asks in the .interop group for more help.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too