|
|
You're in the
dotnet interop
group:Is there any way to hack around C#'s lack of support for optional arguments?
dotnet interop:
function with arguments (IDL form) that look like: Foo( [in, string] LPCWSTR wPath, [out, OPTIONAL] VARIANT *pdata, [out, OPTIONAL] long *plFlags); I can translate this, successfully, to: Foo( string sPath, [out] object data, [ref] int flags) but I have no way of testing whether the incoming "data" and "flags" references are valid. If the caller passes in NULL, there seems to be no way of testing this in C#. I can put a try/catch block around assignments to these, but this is really slow in the NULL case. Is it totally fruitless to try to deal with optional arguments? Arguably, it's not even strictly an issue with arguments tagged as optional. I can imagine an interface that omits the OPTIONAL keyword but simply documents that NULL pointer values are acceptable. How can this condition (invalid references) be tested in C#? My apologies if this has been covered already. A search of the newsgroup titles didn't show up any promising postings.
You can overload the method as in:
Foo(sting sPath) Foo(string sPath, VARIANT *pdata) Foo(string sPath, long *plFlags) Foo(string sPath, VARIANT *pdata, long *plFlags) Have the first three methods call the last with null (or some predefined value) passed in. The forth method will do your busy work. This will give you control over what is passed in and there are no optional parameters. Hope that helps. Mike Kuehn [quoted text, click to view] "Manny Vellon" <mvellon@vellon.com> wrote in message news:%23apeL7UNFHA.568@TK2MSFTNGP09.phx.gbl... >I am trying to implement a COM interface in my app that has a member >function with arguments (IDL form) that look like: > > Foo( [in, string] LPCWSTR wPath, > [out, OPTIONAL] VARIANT *pdata, > [out, OPTIONAL] long *plFlags); > > I can translate this, successfully, to: > > Foo( string sPath, [out] object data, [ref] int flags) > > but I have no way of testing whether the incoming "data" and "flags" > references are valid. If the caller passes in NULL, there seems to be no > way of testing this in C#. I can put a try/catch block around assignments > to these, but this is really slow in the NULL case. > > Is it totally fruitless to try to deal with optional arguments? Arguably, > it's not even strictly an issue with arguments tagged as optional. I can > imagine an interface that omits the OPTIONAL keyword but simply documents > that NULL pointer values are acceptable. How can this condition (invalid > references) be tested in C#? > > My apologies if this has been covered already. A search of the newsgroup > titles didn't show up any promising postings. > > >
[quoted text, click to view] "Manny Vellon" <mvellon@vellon.com> wrote in message news:%23apeL7UNFHA.568@TK2MSFTNGP09.phx.gbl... > I am trying to implement a COM interface in my app that has a member > function with arguments (IDL form) that look like: > > Foo( [in, string] LPCWSTR wPath, > [out, OPTIONAL] VARIANT *pdata, > [out, OPTIONAL] long *plFlags); > > I can translate this, successfully, to: > > Foo( string sPath, [out] object data, [ref] int flags) > > but I have no way of testing whether the incoming "data" and "flags" > references are valid. If the caller passes in NULL, there seems to be no way > of testing this in C#. I can put a try/catch block around Can't you write this: if (data == null)
[quoted text, click to view]
> Can't you write this: > if (data == null) No. In .net interop, what is (in c++): void foo(int *pdata) becomes void foo(out pdata) and pdata is _not_ a pointer. Within C#, there is no way to pass a bad reference to foo, but when calling from C++ to C#, you could call foo(NULL) and the C# code would gag. When you test pdata==null, you are not testing a pointer like you do in C++; you are testing the value. The value might very well be null before you assign to it. The question is whether the reference is something valid that you can assign to.
I don't see how you can do this when implementing a COM interface. When your
code is called via such an interface, you can't implement overloaded methods - the app is only aware of what's in the interface (for that matter, that's true when you're called via a C# interface, too). Additionally, remember, this is C# - your examples mention VARIANT's and pointers - you're thinking C++. The VARIANT * becomes a "ref object" and the "long *plFlags" becomes a "ref long". If I was doing this in C++ I could simply check to see if pdata or plFlags was NULL. [quoted text, click to view] "Kuehn" <IdontWant@spam.com> wrote in message news:Ws2dnffQ9Nx6udbfRVn-iw@seanet.com... > You can overload the method as in: > Foo(sting sPath) > Foo(string sPath, VARIANT *pdata) > Foo(string sPath, long *plFlags) > Foo(string sPath, VARIANT *pdata, long *plFlags) > > Have the first three methods call the last with null (or some predefined > value) passed in. The forth method will do your busy work. This will give > you control over what is passed in and there are no optional parameters. > > Hope that helps. > > Mike Kuehn > > > > "Manny Vellon" <mvellon@vellon.com> wrote in message > news:%23apeL7UNFHA.568@TK2MSFTNGP09.phx.gbl... >>I am trying to implement a COM interface in my app that has a member >>function with arguments (IDL form) that look like: >> >> Foo( [in, string] LPCWSTR wPath, >> [out, OPTIONAL] VARIANT *pdata, >> [out, OPTIONAL] long *plFlags); >> >> I can translate this, successfully, to: >> >> Foo( string sPath, [out] object data, [ref] int flags) >> >> but I have no way of testing whether the incoming "data" and "flags" >> references are valid. If the caller passes in NULL, there seems to be no >> way of testing this in C#. I can put a try/catch block around assignments >> to these, but this is really slow in the NULL case. >> >> Is it totally fruitless to try to deal with optional arguments? Arguably, >> it's not even strictly an issue with arguments tagged as optional. I can >> imagine an interface that omits the OPTIONAL keyword but simply documents >> that NULL pointer values are acceptable. How can this condition (invalid >> references) be tested in C#? >> >> My apologies if this has been covered already. A search of the newsgroup >> titles didn't show up any promising postings. >> >> >> > >
Do you try the "System.Reflection.Missing.Value"?
It is like the "IsMissing" in VB6.0 and "IsNothing" in VB.net. Egghead [quoted text, click to view] "Manny Vellon" <mvellon@vellon.com> wrote in message news:%23apeL7UNFHA.568@TK2MSFTNGP09.phx.gbl... >I am trying to implement a COM interface in my app that has a member >function with arguments (IDL form) that look like: > > Foo( [in, string] LPCWSTR wPath, > [out, OPTIONAL] VARIANT *pdata, > [out, OPTIONAL] long *plFlags); > > I can translate this, successfully, to: > > Foo( string sPath, [out] object data, [ref] int flags) > > but I have no way of testing whether the incoming "data" and "flags" > references are valid. If the caller passes in NULL, there seems to be no > way of testing this in C#. I can put a try/catch block around assignments > to these, but this is really slow in the NULL case. > > Is it totally fruitless to try to deal with optional arguments? Arguably, > it's not even strictly an issue with arguments tagged as optional. I can > imagine an interface that omits the OPTIONAL keyword but simply documents > that NULL pointer values are acceptable. How can this condition (invalid > references) be tested in C#? > > My apologies if this has been covered already. A search of the newsgroup > titles didn't show up any promising postings. > > >
[quoted text, click to view]
>Is it totally fruitless to try to deal with optional arguments? Arguably, >it's not even strictly an issue with arguments tagged as optional. I can >imagine an interface that omits the OPTIONAL keyword but simply documents >that NULL pointer values are acceptable. How can this condition (invalid >references) be tested in C#? The only way I can think of is to modify the interop assembly and change the parameter types to IntPtr or int*. If you for example change the plFlags type to int* (forcing you to use unsafe code in C#) you can then write if ( flags != null ) *flags = 123; Mattias -- Mattias Sjögren [MVP] mattias @ mvps.org http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com
This works fine for the int pointers, but there's also a VARIANT * in the
interface that requires some special handling. For the ints, there's some functions in the Marshal class that lets you treat IntPtrs as memory addresses and lets you write values into them without using unsafe code. Thx. [quoted text, click to view] "Mattias Sjögren" <mattias.dont.want.spam@mvps.org> wrote in message news:OYZmGCwNFHA.3512@TK2MSFTNGP15.phx.gbl... > >Is it totally fruitless to try to deal with optional arguments? Arguably, >>it's not even strictly an issue with arguments tagged as optional. I can >>imagine an interface that omits the OPTIONAL keyword but simply documents >>that NULL pointer values are acceptable. How can this condition (invalid >>references) be tested in C#? > > The only way I can think of is to modify the interop assembly and > change the parameter types to IntPtr or int*. If you for example > change the plFlags type to int* (forcing you to use unsafe code in C#) > you can then write > > if ( flags != null ) > *flags = 123; > > > > Mattias > > -- > Mattias Sjögren [MVP] mattias @ mvps.org > http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com > Please reply only to the newsgroup.
Is there a "Set" analog? If the interface passes a VARIANT * and I translate
this to IntPtr (so that I can test the incoming pointer value), I'd need a "set", but it's not as simple as calling the Marshal.Write's because I need a CCW for the object I'm returning. Another solution that I'm pursuing (as per some reading I've done) is to declare the interfaces as arrays: foo(VARIANT *po, int *pv) becomes foo(object[] po, int [] pv) then I can test po and pv and return values via po[0]= and pv[0]=. This should work although it looks weird. [quoted text, click to view] "Nick Hall" <nickh@aslan.nospam.co.uk> wrote in message news:u9cMb7QOFHA.4028@tk2msftngp13.phx.gbl... > There's also a couple of functions for dealing with variants > (GetObjectForNativeVariant/GetNativeVariantForObject) which can be used to > similar effect. > > Hope this helps, > > Nick Hall > > "Manny Vellon" <mvellon@vellon.com> wrote in message > news:%23oBi789NFHA.2468@tk2msftngp13.phx.gbl... >> This works fine for the int pointers, but there's also a VARIANT * in >> the interface that requires some special handling. For the ints, there's >> some functions in the Marshal class that lets you treat IntPtrs as memory >> addresses and lets you write values into them without using unsafe code. >> >> Thx. >> >> "Mattias Sjögren" <mattias.dont.want.spam@mvps.org> wrote in message >> news:OYZmGCwNFHA.3512@TK2MSFTNGP15.phx.gbl... >>> >Is it totally fruitless to try to deal with optional arguments? >>> >Arguably, >>>>it's not even strictly an issue with arguments tagged as optional. I can >>>>imagine an interface that omits the OPTIONAL keyword but simply >>>>documents >>>>that NULL pointer values are acceptable. How can this condition (invalid >>>>references) be tested in C#? >>> >>> The only way I can think of is to modify the interop assembly and >>> change the parameter types to IntPtr or int*. If you for example >>> change the plFlags type to int* (forcing you to use unsafe code in C#) >>> you can then write >>> >>> if ( flags != null ) >>> *flags = 123; >>> >>> >>> >>> Mattias >>> >>> -- >>> Mattias Sjögren [MVP] mattias @ mvps.org >>> http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com >>> Please reply only to the newsgroup. >> >> > >
There's also a couple of functions for dealing with variants
(GetObjectForNativeVariant/GetNativeVariantForObject) which can be used to similar effect. Hope this helps, Nick Hall [quoted text, click to view] "Manny Vellon" <mvellon@vellon.com> wrote in message news:%23oBi789NFHA.2468@tk2msftngp13.phx.gbl... > This works fine for the int pointers, but there's also a VARIANT * in the > interface that requires some special handling. For the ints, there's some > functions in the Marshal class that lets you treat IntPtrs as memory > addresses and lets you write values into them without using unsafe code. > > Thx. > > "Mattias Sjögren" <mattias.dont.want.spam@mvps.org> wrote in message > news:OYZmGCwNFHA.3512@TK2MSFTNGP15.phx.gbl... >> >Is it totally fruitless to try to deal with optional arguments? >> >Arguably, >>>it's not even strictly an issue with arguments tagged as optional. I can >>>imagine an interface that omits the OPTIONAL keyword but simply documents >>>that NULL pointer values are acceptable. How can this condition (invalid >>>references) be tested in C#? >> >> The only way I can think of is to modify the interop assembly and >> change the parameter types to IntPtr or int*. If you for example >> change the plFlags type to int* (forcing you to use unsafe code in C#) >> you can then write >> >> if ( flags != null ) >> *flags = 123; >> >> >> >> Mattias >> >> -- >> Mattias Sjögren [MVP] mattias @ mvps.org >> http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com >> Please reply only to the newsgroup. > >
I'd have thought that's where GetNativeVariantForObject would come in. From
the looks of the documentation it looks like it would be something like the following: - if (pData != IntPtr.Zero) { GetNativeVariantForObject(ObjectToStoreInVariant, pData); } In other words GetNativeVariantForObject does the work of creating the CCW (if required) and writing to the supplied Variant. Hope this helps, Nick Hall [quoted text, click to view] "Manny Vellon" <mvellon@vellon.com> wrote in message news:OzO6T9SOFHA.244@TK2MSFTNGP12.phx.gbl... > Is there a "Set" analog? If the interface passes a VARIANT * and I > translate this to IntPtr (so that I can test the incoming pointer value), > I'd need a "set", but it's not as simple as calling the Marshal.Write's > because I need a CCW for the object I'm returning. > > Another solution that I'm pursuing (as per some reading I've done) is to > declare the interfaces as arrays: > > foo(VARIANT *po, int *pv) > > becomes > > foo(object[] po, int [] pv) > > then I can test po and pv and return values via po[0]= and pv[0]=. This > should work although it looks weird. > > "Nick Hall" <nickh@aslan.nospam.co.uk> wrote in message > news:u9cMb7QOFHA.4028@tk2msftngp13.phx.gbl... >> There's also a couple of functions for dealing with variants >> (GetObjectForNativeVariant/GetNativeVariantForObject) which can be used >> to similar effect. >> >> Hope this helps, >> >> Nick Hall >> >> "Manny Vellon" <mvellon@vellon.com> wrote in message >> news:%23oBi789NFHA.2468@tk2msftngp13.phx.gbl... >>> This works fine for the int pointers, but there's also a VARIANT * in >>> the interface that requires some special handling. For the ints, there's >>> some functions in the Marshal class that lets you treat IntPtrs as >>> memory addresses and lets you write values into them without using >>> unsafe code. >>> >>> Thx. >>> >>> "Mattias Sjögren" <mattias.dont.want.spam@mvps.org> wrote in message >>> news:OYZmGCwNFHA.3512@TK2MSFTNGP15.phx.gbl... >>>> >Is it totally fruitless to try to deal with optional arguments? >>>> >Arguably, >>>>>it's not even strictly an issue with arguments tagged as optional. I >>>>>can >>>>>imagine an interface that omits the OPTIONAL keyword but simply >>>>>documents >>>>>that NULL pointer values are acceptable. How can this condition >>>>>(invalid >>>>>references) be tested in C#? >>>> >>>> The only way I can think of is to modify the interop assembly and >>>> change the parameter types to IntPtr or int*. If you for example >>>> change the plFlags type to int* (forcing you to use unsafe code in C#) >>>> you can then write >>>> >>>> if ( flags != null ) >>>> *flags = 123; >>>> >>>> >>>> >>>> Mattias >>>> >>>> -- >>>> Mattias Sjögren [MVP] mattias @ mvps.org >>>> http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com >>>> Please reply only to the newsgroup. >>> >>> >> >> > >
Cool - I'll have to experiment with this. At worst, I can imagine that it
would only do simple types (integers, strings, etc.), but it would be great if it also handled the creation of a CCW! [quoted text, click to view] "Nick Hall" <nickh@aslan.nospam.co.uk> wrote in message
news:uv4VCPdOFHA.2132@TK2MSFTNGP14.phx.gbl... > I'd have thought that's where GetNativeVariantForObject would come in. > From the looks of the documentation it looks like it would be something > like the following: - > > if (pData != IntPtr.Zero) > { > GetNativeVariantForObject(ObjectToStoreInVariant, pData); > } > > In other words GetNativeVariantForObject does the work of creating the CCW > (if required) and writing to the supplied Variant. >
Don't see what you're looking for? Try a search.
|
June 2003
July 2003
August 2003
September 2003
October 2003
November 2003
December 2003
January 2004
February 2004
March 2004
April 2004
May 2004
June 2004
July 2004
August 2004
September 2004
October 2004
November 2004
December 2004
January 2005
February 2005
March 2005
April 2005
May 2005
June 2005
July 2005
August 2005
September 2005
October 2005
November 2005
December 2005
January 2006
February 2006
March 2006
April 2006
May 2006
June 2006
July 2006
August 2006
September 2006
October 2006
November 2006
December 2006
January 2007
February 2007
March 2007
April 2007
May 2007
June 2007
July 2007
August 2007
September 2007
October 2007
November 2007
December 2007
January 2008
February 2008
March 2008
April 2008
May 2008
June 2008
| home · blog · groups | Questions? Comments? Contact the dn |