>>>>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
>
>Interesting, it looks like a known issue. That is mentioned in these two links:
>
>
http://support.microsoft.com/?kbid=316581>
http://social.msdn.microsoft.com/Forums/en-US/vblanguage/thread/b8e26285-1f2a-4a1a-9ca4-9d198d0bd9dd/>
>You might want to let the supplier of your 3rd party dll know about it...
Hmmm, I'd come across your second link but it was mainly about VB properties declared as 'Variant' so I only skimmed it. The MS link cites actual errors occuring from NET classes implementing the COM interface. I'm not actually confronted with show-stopping errors - just a messy interface. I will, however, pass the links on to the 3rd party providers.
Thx,
Viv
