views:

111

answers:

2

I'm looking at the Interop UserControl mechanism that's part of the "Interop Forms Toolkit" version 2.0. (This you to build a .Net UserControl that can be published as a COM object for use on VB6 forms.)

I've started a new project using the "VB6 Interop UserControl" template, and what I see is a class definition that looks like this:

    <ComClass(InteropUserControl.ClassId, InteropUserControl.InterfaceId,       
        InteropUserControl.EventsId)> _
    Public Class InteropUserControl

  + VB6 Interop Code

        'Please enter any new code here, below the Interop code

    End Class

without any "Inherits" statement. But if I look in the Class Browser, I can see that this class (not surprisingly) inherits from the WinForms UserControl class. How can it be that the "Inherits UserControl" piece of the class declaration isn't visible anywhere?

Question 634559 also shows an InteropUserControl class declaration without any "inherits UserControl" statement. I must be missing something simple from my VB.Net knowledge. (I do most of my .Net work in C#.)

Any help in understanding this would be appreciated.

A: 

I believe <ComClass()> acts as a signal to the compiler to add some interfaces.

I've found one source for that behavior.

It's possible that a similiar rewrite occurs for Inherits in this case.

Kevin Montrose
I read the referenced article, and though the info is interesting and relevant to what I'm doing, there's nothing there that suggests that an attribute can change the base class of the class in which the attribute is present.I'm still wondering how a class definition can fail to include an "inherits" clause, but the system still mystically figures out the base class.
There's obviously some rewriting going on somewhere to add an inherits clause, even if it never appears in source. The article shows that such behavior in response to an attribute is not unprecedented , even though the exact behavior (adding an `Implements` clause) differs from your case.
Kevin Montrose
"rewriting" is *exactly* what all attributes do, in the sense that they alter to generated code/IL.
RBarryYoung
A: 

The VB.Net compiler adds Inherits UserControl automatically. Take a look at your class using Reflector to see this. In addition to this, it adds Implements _InteropUserControl. So when you write your class like this:

<ComClass(InteropUserControl.ClassId, InteropUserControl.InterfaceId,
    InteropUserControl.EventsId)> _
Public Class InteropUserControl

    ...

It'll come out looking something like this in Reflector:

<DesignerGenerated(), ComClass("a2ee6169-9a0d-4930-b8bb-ee71307c43b3",
    "75ff3d57-6448-40ac-a294-68252180cacd", "2b04895c-43f8-44b3-b187-00556ef53a6a"),
    Guid("a2ee6169-9a0d-4930-b8bb-ee71307c43b3"),
    ClassInterface(ClassInterfaceType.None),
    ComSourceInterfaces("VBControl.InteropUserControl+__InteropUserControl")> _
Public Class InteropUserControl
    Inherits UserControl
    Implements _InteropUserControl

    ...
Gabriel McAdams
I could tell that this was happening under the covers. The question I want answered is, what told the VB.Net compiler to do this? It seems odd that the indication that the new class should descend from UserControl (and implement _InteropUserControl) seems to be completely invisible.
What do you mean? The attribute itself told the compiler to add that. Just like writing Public Class tells the compiler something, attributes tell the compiler something too.
Gabriel McAdams