Interfaces

I have an ActiveX Control project (CMSSecurity). It contains one UserControl (ICMSPassword) which Implements an ICMSPlugin interface. It includes all the properties/subs/functions from the ICMSPlugin interface, plus several of its own (which make up it's ICMSPlugin interface, right?).

In another application, I have an objPlugin variable of type ICMSPlugin, and an objPass variable of type ICMSPassword. objPlugin holds a reference to the ICMSPlugin interface on a dynamically created instance of the CMSSecurity.ICMSPassword control. Shouldn't I be able to do set objPass = objPlugin

to get a reference to that control's ICMSPassword interface? When I do this I get a Type Mismatch error.

In the project which references the ICMSPassword control, when I go to Project/Componants, it lists CMSSecurity on two lines. One refers to the .VBP and the other refers to the .OCX. Is this a sign that something's wrong or is this normal? I've tried checking both of them (not at the same time) and either way I get the Type Mismatch error. I've tried running RegClean but it didn't help.

-----
Lee Perkins
TigerBase Technologies

I think you have to first do the following:

dim ojbPlugin as ICMSPlugin

Then the line set objPass = objPlugin should work.

Charlie Zimmerman
http://www.freevbcode.com

I think you have to first do the following:

dim objPlugin as ICMSPlugin

Then the line

set objPass = objPlugin

should work.

Charlie Zimmerman
http://www.freevbcode.com

I think what I'm trying to do should work. I think something else is wrong. Take a look at this:
Dim objPlugin as ICMSPlugin
Dim objPass as CMS_Security.ICMSpassword ' Tried just "ICMSpassword" also
Dim objObject as Object

set objPlugin = CreateObject("CMS_Security.ICMSpassword")
set objObject = CreateObject("CMS_Security.ICMSpassword")
set objPass = CreateObject("CMS_Security.ICMSpassword")



The "Set objPlugin =" line works and gets the ICMSPlugin interface.
The "Set objObject =" line works and gets the ICMSpassword interface.
The "Set objPass =" line fails with a Type Mismatch error.

I've unregistered CMS_Security.ocx, removed all references to CMS_Security and ICMSpassword from my registry, ran RegClean, and recompiled CMS_Security and the application that uses it and still get this problem. What in the WORLD am I doing wrong? :)

BTW, I no longer have multiple lines in the Project/Components list for CMS_Security now that I cleaned up the registry.

-----
Lee Perkins
TigerBase Technologies

It's a weird situation, because it seems that VB recognizes that ICMSpassword implements ICMSplugin, yet it does not recognize ICMSpassword as a valid object in itself.

Just guessing, but it may be possible that the application is looking for the previous version of ICMSpassword. Try unchecking the reference to ICMSpassword in the references list, closing the references, then opening up the references list and browsing to the correct, newly compiled version of CMS_Security.

I unregistered CMS_Security.ocx, deleted all copies of CMS_Security.ocx, removed all references to CMS_Security and ICMSpassword from the registry, removed the component reference to CMS_Security from the application project, quit VB, cleaned up the CMS_Security project directory (removed the .lib, .exp, etc... compile time generated files), restarted VB, opened the project group, recompiled CMS_Security, copied CMS_Security.ocx to another directory, set Binary Compatibility to the copy of the OCX (just to make sure my interfaceID's are changing on me), added the component reference CMS_Security back to the application project, recompiled it, ran it, and sure enough... as soon as it hits the line:
set objPass = objPlugin


it throws up a Type Mismatch error.

Could this have anything to do with the fact the CMS_Security is a ActiveX Control (not an Active DLL)? Is there some reason in VB why you can't get the UserControl's "native" interface through another interface reference on that same object? I know you can't say
Dim objPass as new ICMSPassword


It just won't let you. But you can say
Dim objPass as ICMSPassword


I'm gonna play with this more using a small project and minimal code.


-----
Lee Perkins
TigerBase Technologies

hey!, in your first post you said ICMSPassowrd is a user Control!. and how can you do a createObject on a user control, It works only for server classes/objects.

Either you do a "set" to an existing instance of a control or you create a run time instance using Me.Controls.add ( VB 6.0) .


Also you said "The "Set objPlugin =" line works and gets the ICMSPlugin interface."..
this is the reference of which instance of interface? Meaning, an interface has be have an implementation right? So to which class/control is this refering to after that line?


II. Back to yout first post :

ICMSPassword is a class that implemets the ICMSPlugin Interface, which means
you can NEVER say

dim objPass as ICMSPassword
dim objPlugin as ICMSPlugin
...
set objPass = objPlugin. ' IS WRONG

Infact it is the other way:
set objPlugin = objPass

because IMPLEMENTS means "is a" relationship holds. So where ever a ICMSPLugin object is required, you can use an instance of ICMSPassword, but you can never use a ICMSplugin where ICMSpassword is required!!.


ICMSPassowrd : Implements ICMSPlugin.
so if there is a function that takes the class/interface CMSPLugin you can pass a
a reference to CMSPassword, because CMSPLugin is wholely contained in CMSPassword.

Think abt it!



RK

I'm a little confused because now you're going back to the code from your first post. In your second post, you presented something slightly different. In the second post, you said set objPass = createObject("ICMSPassword") didn't work, and I was not sure why. But here and in your first post, you are trying to assign an object to an interface variable, and this won't work. Instead, you have to do the opposite -- dim an instance of the interface variable and then assign the interface variable to an instance of the object variable. You can then access the object's implementation of that interface via the interface variable.

Charlie Zimmerman
http://www.freevbcode.com

You're thinking strictly VB here. We're dealing with the world of COM. An object has multiple interfaces. From any interface on an object, you can call QueryInterface(...) and get a reference to any other interface on the object. This is one of the rules of COM. VB handles the grunt work of calling QueryInterface for you behind the scenes. All you have to do is assign an interface reference variable to a variable of another interface type and VB will call QueryInterface on the assigned interface to request the new interface. If it fails... Type Mismatch. If it doesn't fail, you have a reference to the other interface on the same object. That's how VB handles COM and multiple interfaces.

As to your other comment, an ActiveX control *IS* a COM server and should therefore be able to be created with CreateObject(<servers ProgID>) with no problem. When you do Me.Controls.Add("<controls ProgID>"), that's essentialy what VB is doing. It's creating an instance of the server dynamically by looking it's ClassID up in the registry via it's ProgID. After all, an .OCX is still an in-proc COM server (ActiveX DLL, whatever you want to call it) it's just renamed to .OCX. The main difference between VB's ActiveX DLL and ActiveX Control project types are what COM interfaces they implement. An ActiveX Control implements a lot of OLE interfaces to all it to be imbedded in a container.

-----
Lee Perkins
TigerBase Technologies

"Shouldn't I be able to do

set objPass = objPlugin "

NO. You should not be able to. See my other positng.

----
Regarding 2 instances: Even i have noticed. and what i could decifer is: it is so because their in-process serves are different. For one it is .ocx file while for the other it is the running instance of VB.exe ( This exists as long as you have VB open only). Look into the registry, you will see both.

This is again the typical case of an interface being implemented by multiple objects.
Your .Ocx file implements the interface identified by the ClassID of the control. and the VB.exe also (in debug mode) registers itself as implementing the same interface, and same class id, and hence you see two references and you can choose between them.


RK

Ok, maybe I'm a little confused in my understanding of how VB handles COM. In COM, an object can have multiple interfaces. If you have any interface on that object, you can get to any other interface on that object by calling QueryInterface() through the interface pointer (reference) you have. That's a fundamental rule of COM. I was under the impression that in VB, you just assigned an variable of one interface type to a variable of another interface type and VB would take care of calling QueryInterface() behind the scenes for you. Given that assumption, if you have an object that has InterfaceA and InterfaceB, you should be able to assign a variable of type InterfaceA to a varialbe of type InterfaceB, and visa versa.

In a VB ActiveX Control project, there is a UserControl. I assumed (Maybe THAT's what I'm doing too much... :)) that the UserControls name was one interface, and any interfaces it "Implements" were additional interfaces.

Using OleView to view the compiled OCX confuses me a little (a lot!) more. It appears that the ActiveX Control project's name is used as the name of the Type Library. The UserControl's name is used as the coClass *AND* the default interface. I always thought the project's name was used to name the coClass, and the UserControl's name was used to name the default interface. Shows how wrong I've been. :) So when I Dim a variable as CMS_Security.ICMSPassword, I'm specifying the Type Library, and the coClass. The variable should be a reference to the default interface on the coClass. Yet in VB, if I do:
Dim objPass as CMS_Security.ICMSPassword


then when I type objPass. the list that comes up of available properties/methods is WAY more than is in the ICMSPassword interface, it's the VB control itself. Ok, I'm throughly confused now on how VB handles COM.

ARGH!!!!! :( It's late (2am almost) and I'm going insane. Time to go to sleep. :)

-----
Lee Perkins
TigerBase Technologies

How VB handles COM is an interesting topic, but if you approach VB coding from a "COM underpinnings" point of view, you will just get confused. The creators of VB purposely hid the details of COM and its implementation from VB developers. Thus, I'd recommend just trying to figure out what you're supposed to do, and not worry about how it relates to COM.

Regarding the other issue, I did not know that you can't use CreateObject on a UserControl, like that other fellow said, because I've never tried it, but I'd assume that's correct, and that's why you are having the trouble you are having.

Good luck, I'm sure you'll have it all working very fast after you wake up tommorrow.

It may be the ooly World of com!. but still it has stick together right?

In your example, your ICMSPlugin doesnot implement the interface ICMSPassword!. and hence it fails.. simple.. (infact it is the other way!)

>"You're thinking strictly VB here.".

VB may be doing the CreateObject and other grunt work of Com behind the scenes. I too understand (some of)the intercasies , it may be doing all but and a "little more", which could be causing the touble :
and my simple point is:
If you program in VB, do the VB way!.

VBs way of query interface is 'TypeOf'.
To know if an object implements an interface or not, Use "is typeof ".


RK

I think what I'm finding out is that in the case of:
Dim objPlugin as ICMSPlugin
Dim objPass as ICMSPassword


My variable objPlugin is a reference to a COM Interface named ICMSPLugin. My variable objPass is of type UserControl ICMSPassword (the UserControl named that, not the COM Interface named that). CreateObject("CMS_Security.ICMSPassword") returns COM interfaces. So... Set objPass = CreateObject(...) tries to assing the COM Interface ICMSPassword to a variable of type UserControl ICMSPassword. Type Mismatch. If this is the case... I need to find a way to make a variable of the COM Interface ICMSPassword type, not the UserControl ICMSPassword type. I'm afraid VB might not let me do this in which case I have to rethink my strategy. This wouldn't be so bad if I wasn't supposed to start burning CD's with this software on it this week for release to the field and it's had no testing yet. ARGH!!!! :) Bet you're glad you're not me, huh? I wish I wasn't me right now. LOL! :)


-----
Lee Perkins
TigerBase Technologies

I think I'm starting to understand what's going on (read my latest reply to czimmerman in this thread). Sorry if I sounded abrupt before, it's just getting late and I'm too close to a dead line to still be sane. :)

-----
Lee Perkins
TigerBase Technologies