By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
446,370 Members | 1,188 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 446,370 IT Pros & Developers. It's quick & easy.

IDispatch definition in C#

P: n/a
Hello,

I am implementing a class in C# that wraps an automation server and am
stuck on something basic. Using the following code fragment:

using System;
using System.Runtime.InteropServices;

namespace ANamespace
{
public class Wrapper
{
private IDispatch* m_Server;

public Wrapper()
{};
}
}

the compiler complains

Wrapper.cs(70): The type or namespace name 'IDispatch' could not be found
(are you missing a using directive or an assembly reference?)

I suspect I am missing something, but I don't know from where to pull the
IDispatch definition in.

Any help is appreciated.

Phil Coveney
Nov 17 '05 #1
Share this Question
Share on Google+
4 Replies


P: n/a
> I suspect I am missing something, but I don't know from where to pull the
IDispatch definition in.


Why do you need it? Why not simply

private object m_Server;
Mattias

--
Mattias Sjögren [MVP] mattias @ mvps.org
http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com
Please reply only to the newsgroup.
Nov 17 '05 #2

P: n/a
Mattias,
Why do you need it? Why not simply
private object m_Server; Fair enough. In fact, that's what I have been doing to make progress on
this project while I am resolving this. And, if this is Microft's intention
for C# developers, I guess that's what I'll do.

But two things trouble me about this.
First, (I think) it implies that I store all standard COM interface
references in object variables. It seems to me unnecessarily hiding
information about the variable's type. One could extend this logic, I
suppose, and note that I could store integer values in object variables,
which I think we can agree would not be good practice.
Second, since I can store references to .NET interfaces, this (I think)
implies I would develop my class distinguishing between standard COM
interfaces, and typelib-imported + non-COM iterfaces. If I change the
provider of a COM interface service from a COM to a non-COM service, does it
mean I change how I store the reference?

OK, I'm not trying to start a deep philosophy discussion. It just seems
strange that Microsoft would thoughtfully prevent the definition of its core
interfaces from being visible to .NET class designers. I am just trying to
understand its rationale.

Thanks for your help,

Phil Coveney

Nov 17 '05 #3

P: n/a
Phil,
t seems to me unnecessarily hiding
information about the variable's type.
Unless you're going to use any type specific functionality (ie
IDispatch methods) I don't see that as a problem.

OK, I'm not trying to start a deep philosophy discussion. It just seems
strange that Microsoft would thoughtfully prevent the definition of its core
interfaces from being visible to .NET class designers.


They don't prevent it, you can declare and use IDispatch if you really
have a reason to. If you do, the field declaration becomes

private IDispatch m_Server;

(not IDispatch*).
Mattias

--
Mattias Sjögren [MVP] mattias @ mvps.org
http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com
Please reply only to the newsgroup.
Nov 17 '05 #4

P: n/a
OK, thanks Mattias.

Nov 17 '05 #5

This discussion thread is closed

Replies have been disabled for this discussion.