Vista - Bug in COM wrapper for write-only properties?

I am scripting with the Perforce (Source Control) COM object, p4com from the
following URL:

http://public.perforce.com/guest/rob...ain/index.html

When PowerShell creates a wrapper for the object, it appears to do "the
wrong thing" on a write-only property, and the property is not accessible.

In this case, the "Input" property is defined as a write-only (propput)
value. When constructed in PowerShell via "New-Object -com "p4com.p4", the
resulting .NET wrapper object does not contain a valid and accessible "Input"
property.

> $p4.Input = "Test"
>
> Exception setting "Input": "Type mismatch. (Exception from HRESULT: 0x80020005 (DISP_E_TYPEMISMATCH))"


Here is a snippet of IDL, taken from OleView on "p4com.p4":

<snip>
interface Ip4 : IDispatch {
<snip>
HRESULT Host([out, retval] BSTR* pVal);
[id(0x00000004), propput, helpstring("property Host")]
HRESULT Host([in] BSTR pVal);
[id(0x00000005), propget, helpstring("property Language")]
HRESULT Language([out, retval] BSTR* pVal);
[id(0x00000005), propput, helpstring("property Language")]
HRESULT Language([in] BSTR pVal);
[id(0x00000006), propget, helpstring("property Password")]
<snip>
[id(0x0000001c), propput, helpstring("Specify input for subsequent
command - e.g. password for login")]
HRESULT Input([in] BSTR rhs);
<snip>

Here is what PowerShell outputs when "p4com.p4" is run thru "member":

TypeName: System.__ComObject#{e7d963d4-7ac8-4b89-b768-16f900db2a93}

Name MemberType Definition
---- ---------- ----------
<snip>
Host Property string Host () {get} {set}
Input Property {get} {set}
Language Property string Language () {get} {set}<snip>

Please note that "Input" does not have a property type, and it has both
getter and setters defined (even though the underlying string is only
settable).

I have a work-around, but it is rather ugly. Please advise if there is a
workaround that would allow the constructed wrapper object to be corrected
such that "$p4.Input" can be assigned a string value.

Thanks!

Posted to Connect

"J Hugard" wrote:

> I am scripting with the Perforce (Source Control) COM object, p4com from the
> following URL:
>
> http://public.perforce.com/guest/rob...ain/index.html
>
> When PowerShell creates a wrapper for the object, it appears to do "the
> wrong thing" on a write-only property, and the property is not accessible.
>
> In this case, the "Input" property is defined as a write-only (propput)
> value. When constructed in PowerShell via "New-Object -com "p4com.p4", the
> resulting .NET wrapper object does not contain a valid and accessible "Input"
> property.
>
> > $p4.Input = "Test"
> >
> > Exception setting "Input": "Type mismatch. (Exception from HRESULT: 0x80020005 (DISP_E_TYPEMISMATCH))"
>
>
> Here is a snippet of IDL, taken from OleView on "p4com.p4":
>
> <snip>
> interface Ip4 : IDispatch {
> <snip>
> HRESULT Host([out, retval] BSTR* pVal);
> [id(0x00000004), propput, helpstring("property Host")]
> HRESULT Host([in] BSTR pVal);
> [id(0x00000005), propget, helpstring("property Language")]
> HRESULT Language([out, retval] BSTR* pVal);
> [id(0x00000005), propput, helpstring("property Language")]
> HRESULT Language([in] BSTR pVal);
> [id(0x00000006), propget, helpstring("property Password")]
> <snip>
> [id(0x0000001c), propput, helpstring("Specify input for subsequent
> command - e.g. password for login")]
> HRESULT Input([in] BSTR rhs);
> <snip>
>
> Here is what PowerShell outputs when "p4com.p4" is run thru "member":
>
> TypeName: System.__ComObject#{e7d963d4-7ac8-4b89-b768-16f900db2a93}
>
> Name MemberType Definition
> ---- ---------- ----------
> <snip>
> Host Property string Host () {get} {set}
> Input Property {get} {set}
> Language Property string Language () {get} {set}<snip>
>
> Please note that "Input" does not have a property type, and it has both
> getter and setters defined (even though the underlying string is only
> settable).
>
> I have a work-around, but it is rather ugly. Please advise if there is a
> workaround that would allow the constructed wrapper object to be corrected
> such that "$p4.Input" can be assigned a string value.
>
> Thanks!