Thanks. Yes, it was c# code. I was looking at another VB code for the same thing, but I use the C# code instead. Is there any documentation that I can use to understand what you did?

I only have one little problem,

Quote:

0:13:15.34>build -I..;c:\dmd\import xtrans.d
xtranslate.d(53): Error: identifier 'OLE_COLOR' is not defined
xtranslate.d(53): Error: OLE_COLOR is used as a type
xtranslate.d(53): Error: cannot have parameter of type void
xtranslate.d(55): Error: identifier 'OLE_COLOR' is not defined
xtranslate.d(55): Error: OLE_COLOR is used as a type
xtranslate.d(55): Error: cannot have parameter of type void

I searched it through the internet, and I found that it is some kind of Property Data Type, http://support.microsoft.com/kb/177629. I am able to comment it out, since for now, I can, at least, compile it. So, I thank you very much.

It's not that different from how you'd traditionally write COM code in C++. But I can see that it might be trickier to translate C#/VB code.

The C# compliler is aware of COM types and does a lot of work under the hood during compilation. It is smart enough to know that TranslateTaskClass is a COM coclass which creates ITranslateTask objects (or rather, a special attribute attached to TranslateTaskClass tell it so). This line in C#

Code:

TranslateTask xtransApp = new TranslateTaskClass()

is merely syntactic sugar for

Code:

// (The C# equivalent of tlbimpd defines two types - ITranslateTask and TranslateTask - which are essentially the same thing. One is an interface, while the other an abstract class.)

The best we can do in D is something like what Juno does: wrapping CoCreateInstance with the coCreate template to make things simpler and cleaner:

Code:

ITranslateTask xtransApp = TranslateTask.coCreate!(ITranslateTask);

Other things to be aware of are types like booleans - C# automatically converts true/false to VARIANT_TRUE/VARIANT_FALSE. The compiler also magically handles COM strings, while you need to use manage them manually with toBStr/fromBStr/freeBStr in D.