[C#] Plugin usable in COM?

[Barabajagal]

Maybe I'm misusing the word object... I mean like if you send a textbox to a function to, say, get its handle and visible status... Something like

Code Select Expand

Public Sub Example(Obj as Object)
Dim ObjWnd as Long
Dim ObjVis as Boolean
    ObjWnd = Obj.hWnd
    ObjVis = Obj.Visible
    MsgBox "The object " & Obj.hWnd & " is " & IIf(ObjVis, "", "not ") & "visible", vbInformation
End Sub
If that was written in a VB6 ActiveX DLL, could a C# program send it a text box?

[MyndFyre]

For your example to work, the textbox that C# would be sending would need to be a COM-visible class that implemented IDispatch (that is, it should be marked with the [InterfaceType] attribute with the values ComInterfaceType.InterfaceIsIDispatch or ComInterfaceType.InterfaceIsDual; and the class interface would also need to expose an hWnd and Visible property.  .NET's control objects do not have an hWnd property, but they do have a Handle property that would make it really easy to implement.  For instance, if you did the following:

Code Select Expand


[ComVisible(true)]
public class ComVisibleTextBox : System.Windows.Forms.TextBox, IComTextBox
{
    public IntPtr hWnd { get { return Handle; } }
    //no need to implement Visible since the parent class already does so.
}

[InterfaceType(ComInterfaceType.InterfaceIsDual)]
[ComVisible(true)]
public interface IComTextBox
{
    IntPtr hWnd { get; }
    bool Visible { get; set; }
}


[Barabajagal]

So objects can be sent through inter-language systems, it's just messy unless it's .NET?
I really don't have any use for this information, it's just somewhat interesting.

[MyndFyre]

So objects can be sent through inter-language systems, it's just messy unless it's .NET?
I really don't have any use for this information, it's just somewhat interesting.

Yes.  The premise behind .NET is language-interoperability; the Common Language Runtime is a definition for how the multiple languages expose the Common Type System.  C# and VB.NET seem very much alike right now because the CTS hadn't really evolved by the time they were released.  On the other hand, there's stuff like IronPython now that can be expressed in the CLR.

COM was Microsoft's real first attempt at exposing reusable components to different languages.  In C++, this is achieved with the help of ATL and Win32 API functions like CoInitialize.  Visual Basic exposed these through ActiveX objects.  COM had a lot of nightmarish programming tasks - registration in the registry, generating type libraries and interface IDs, and versioning, the name a few.  It doesn't HAVE to be messy, but it frequently is.

[Chriso]

That being said would it be possible to send a Visual Basic Class to C# via the object type declaration? Couldn't you do something like you did with the textbox example to "expose" the members of the Visual Basic Class in C#?

[Barabajagal]

Just turn the vb class into an ActiveX DLL, reference it in C# like you would any other DLL, and call its subs/functions and use its variables and constants? If the class is part of a VB EXE, just make it do the same thing

[MyndFyre]

That being said would it be possible to send a Visual Basic Class to C# via the object type declaration? Couldn't you do something like you did with the textbox example to "expose" the members of the Visual Basic Class in C#?

To utilize C# with *any* kind of cleanliness, you have to use early binding, and C# needs to see the type library.

There are ways to incorporate late binding with C#, using the Activator class specifically, and this involves using Reflection to get information about the parameters exposed by the object.  That would mean doing something along the lines of:

Code Select Expand


Type vbType = Type.GetTypeFromProgID("MyVBBot.SomeClass");
object vbObj = Activator.CreateInstance(vbType);
vbType.InvokeMember("Visible", BindingFlags.SetProperty, null, vbObj, new object[] { true });


Do you get the idea?  VERY ugly.

[Chriso]

Yeah I get the idea, thanks.