[lnkForumImage]
TotalShareware - Download Free Software

Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

microsoft.public.dotnet.framework.interop

exposing .net methods through interfaces?

Andrew Brook

11/1/2007 2:41:00 PM

Hi Everyone,

I have a .NET 2.0 set of classes that i've recently attempted to call from
an MFC application using regasm to generate and register a type library. I
didn't author my classes with the intention that they would be called from
an unmanaged application and i've run into a few problems.

Let's say for example that i have a Class A. I could see this class in the
MFC app, but i couldn't see any of it's public methods or properties. It
wasn't until I made Class A implement Interface A that I could see the
methods using the interface and the following code

IClassA clsA(__uuidof(ClassA));

But what if I want Class A to inherit from two interfaces. If I can indeed
only access my methods using the interface, do I have to create two
variables, one for each interface?

I'm seriously hoping i've got something wrong along the way :)

thanks,
Andrew


2 Answers

Foz

11/2/2007 1:57:00 PM

0

Hi Andrew,

If an object exposes multiple interfaces, you need a separate interface
variable to access each one. This allows clients to program to an interface
rather than implementation and affords decoupling. This is good practice in
general, so that when someday you need to replace ClassA with SomeOtherAClass
your clients only need to update the CoClass.

"Andrew Brook" wrote:

> Hi Everyone,
>
> I have a .NET 2.0 set of classes that i've recently attempted to call from
> an MFC application using regasm to generate and register a type library. I
> didn't author my classes with the intention that they would be called from
> an unmanaged application and i've run into a few problems.
>
> Let's say for example that i have a Class A. I could see this class in the
> MFC app, but i couldn't see any of it's public methods or properties. It
> wasn't until I made Class A implement Interface A that I could see the
> methods using the interface and the following code
>
> IClassA clsA(__uuidof(ClassA));
>
> But what if I want Class A to inherit from two interfaces. If I can indeed
> only access my methods using the interface, do I have to create two
> variables, one for each interface?
>
> I'm seriously hoping i've got something wrong along the way :)
>
> thanks,
> Andrew
>
>
>

Andrew Brook

11/8/2007 3:16:00 PM

0

Thanks for your response,

I guess this just means I need to design my classes a little better with
this in mind, good job i'm still at the design stage of this! :)

thanks again,
Andrew

"Foz" <Foz@discussions.microsoft.com> wrote in message
news:5DDBECBD-20F1-429B-AAEE-638CA7ED91A0@microsoft.com...
> Hi Andrew,
>
> If an object exposes multiple interfaces, you need a separate interface
> variable to access each one. This allows clients to program to an
> interface
> rather than implementation and affords decoupling. This is good practice
> in
> general, so that when someday you need to replace ClassA with
> SomeOtherAClass
> your clients only need to update the CoClass.
>
> "Andrew Brook" wrote:
>
>> Hi Everyone,
>>
>> I have a .NET 2.0 set of classes that i've recently attempted to call
>> from
>> an MFC application using regasm to generate and register a type library.
>> I
>> didn't author my classes with the intention that they would be called
>> from
>> an unmanaged application and i've run into a few problems.
>>
>> Let's say for example that i have a Class A. I could see this class in
>> the
>> MFC app, but i couldn't see any of it's public methods or properties. It
>> wasn't until I made Class A implement Interface A that I could see the
>> methods using the interface and the following code
>>
>> IClassA clsA(__uuidof(ClassA));
>>
>> But what if I want Class A to inherit from two interfaces. If I can
>> indeed
>> only access my methods using the interface, do I have to create two
>> variables, one for each interface?
>>
>> I'm seriously hoping i've got something wrong along the way :)
>>
>> thanks,
>> Andrew
>>
>>
>>