Interop and not passing optional out params

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

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
 
spammy said:
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:
Click to expand...

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 said:
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?
Click to expand...

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
 
spammy said:
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.
Click to expand...

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?
Click to expand...

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?
Click to expand...

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 said:
If you're passing information in which ends up being read, it shouldn't
be an out parameter.
Click to expand...

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.
Click to expand...

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.
Click to expand...

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

Spammy
 
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
 
Cor Ligthert said:
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?
Click to expand...

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