>>Hi,
>>
>>I'm consuming a third party COM dll in .NET. When viewed in the .NET object browser all of it's public R/W properties show up as accessible only via get and set methods (other properties that are R/O *do* appear as properties) I queried this with them and was told this was standard behaviour.
>>
>>I have some VB6 DLL of my own here so decided to test their assumption. When I add a reference to my own DLL's all of their numerous public properties are exposed normally. Or I should say all except one. Several of the VB controls have a property of the same name and type - and this property is exposed via get_PropertyName() and set_PropertyName() in all of them.
>>
>>Now obviously the third party developers are incorrect in claiming their DLL is exposed in a normal fashion. But as my DLL indicates there is *something* that causes this behaviour. Anyone know what it is?
>>
>>Best,
>>Viv
>
>You didn't mention what the 3rd party com interop dll is written in.
>
>While his articles were focused on com interop between vfp and .net, he covers a lot of the configuration requirements to expose via com interop:
>
>http://www.west-wind.com/WebLog/posts/3972.aspx
>
>I've followed it from both vfp and .net successfully. He has an article somewhere on his website for has to be done in a .net dll to expose via com interop as well...

Hi,

Not sure but I think the DLL is almost certainly from VB6 code.
I've read Rick's paper but I can't see anything relevant to this problem. At the moment I'm just concentrating on what's happening when I access my own DLL - I've got the VB source for that and can experiment with it.

HA! Just spotted the difference:
If the properties Let() in VB6 doesn't specifically mark the incoming value as 'ByVal' then you need get/sets to access it. That sort of makes sense - but I thought the default in old VB was ByVal anyway. And it doesn't explain why on earth the third party guys would have used ByRef all the time - guess I'll just put a wrapper around it to simplify access.....

Best,
Viv