for the benefit of being lazy

Published November 05, 2004
Advertisement
Spent more time playing with a throw away side project today than I intended to. I had forgotten how much C#'s COM interop annoys me.

Back on the actual planned project arena, I spent more time than I intended trying to come up with a mark up scheme for the personal wiki project. At this point I think I'm just going to say "the heck with it" and implement a really basic markup, just enough to get to work on the back end stuff. Probably just []-style links with no pretty names or escaping right now. Once that's in place I'll start seeing about handling the navigation events from the embedded browser.

As I've mentioned, right now I have IE embedded as a display control. It's a fairly simple process to pipe raw HTML into it. I've been thinking about trying Gecko out instead. If I can get all that to work, I might have all the building blocks I need for one of the subsystems I wanted to put into Seventh Star. That would be neat.

Yay, this project actually ties back into game development some how.
0 likes 2 comments

Comments

bL0wF1sH
Just curious. What things bother you about C#'s COM interop?
November 05, 2004 10:29 AM
SiCrane
Where to start... well my first complaint would be that even when you have an existing type library, the automatic import (w/ .NET 2003 anyways) often leaves something to be desired. For example, my current project I'm working on imports ShDocVw.dll. So there's a nice happy Interop.ShDocVw.dll file sitting in my project directory. However, the types seem to be imperfectly loaded into the IDE. For example, AxSHDocVw.DWebBrowserEvents2_BeforeNavigate2Event shows no members in the Object Browser; however, that information does exist in the interop assembly, since ildasm shows all the members happily, and using those members in source code compiles properly.

But when you don't have a type library, that's where the real fun begins. COM interfaces are represented by C# interfaces, which is fair enough. However, C# interfaces can't inherit from one another, which means that instead if you need to write an interface class with inheritance, you need to manually duplicate the function signatures in the child interfaces, and in implementation classes, you have to remember in implement both the child and the parent interfaces. Otherwise you might have strangeness like IPersistStreams that aren't IPersists. This is a level of hassle that implementing a COM interface in C++ doesn't have. And I don't think I should have to explain just how wrong *that* is.

Then you have the joy of decoding function signatures from IDL files or C/C++ headers into C# declarations. And there's decomposing structure types as well. When all is said and done, with the attributes you need to plaster on everything to make sure that everything is compatible, you've probably written more code than the equivalent C++ implementation, and you're less sure that everything works properly (should I have declared this as a [MarshalAs(UnmanagedType.Interface)] out Object or maybe a [MarshalAs(UnmanagedType.IUnknown)] ref Object?). See the above just wrong comment.

I could go on, but there's not much point. Let's just say I'm looking forward to the next version of C# to see if they streamlined things any better.
November 05, 2004 01:46 PM
You must log in to join the conversation.
Don't have a GameDev.net account? Sign up!
Profile
Author
Advertisement

Latest Entries

New bug to me

1910 views

Week/Class 9

1740 views

Week/Class 8

1788 views

Week/Class 7

1835 views

The promised files

2115 views

Week/Class 6

1518 views

Week/Session 5

1578 views

Week/Session 4

1519 views

On the soapbox

1636 views

Week/Session 3

1493 views
Advertisement