Interfaces

I don't think your strategy is off base, just your syntax. If you have the user control on the form, you can just do what Ravi suggested, in one of the previous messages: use me.controls.add to dynamically load the control. If it is not on a form, you can either add an invisible form to your project and put the control there, or compile the ICMSPassword object as an Active X dll rather than an Active X control.

It's not quite that simple for me. :) I've greatly simplified my actual scenario here to make it easier to concentrate on the problem. In reality, the "Application" I've been refering to is another ActiveX Control (CMS_Reports) which has 3 UserControls (ICSMFranchiseReports, ICMSBookkeeperReports and ICMSTransmiterReports). And there are about 20 other ActiveX Control projects with one or more UserControls each. All these UserControls (including CMS_Security.ICMSPassaword) are "plugins" to a central Standard EXE project which is known genericaly as the "Framework". The framework has a Parent MDI form, and a single child MDI form. The framework creates a new child MDI form and the form dynamically adds one of the controls to itself. A control on a form can request that the framework create another child window and gives the framework the ProgID of the control to place on the window. All the controls implement the ICMSPlugin interface, so the framework returns the ICMSPlugin interface reference to the control that requested the window be created. It's in one of those controls (CMS_Reports.ICMSBookkeeperReports) that I'm requesting the framework create a CMS_Security.ICMSPassword window. The framework gives me back the ICMSPlugin interface reference to the control it just created. Given only that ICMSPlugin reference, I need to acquire a referenc to the control's ICMSPassword interface. That's the frame of mind I was in when I started this thread. I see now that I may have to have the framework return a generic Object to the requesting control (since the framework has no idea what kind of objects it's creating, only that they must implement ICMSPlugin). Either way, I'll work something out tomorrow.


-----
Lee Perkins
TigerBase Technologies

*** LOL **.
I think it rather too late to decide if you should gone for active-x control or dll or server (exe). incidentally all are COM!.

It is one of the first design considerations.. well before burning CDs :-)

I think, your understanding is what my understanding too is. CreateObject creates an instance of the class, it is a pointer to the interface and a little more.. that little more (a bit more because it is a control ), you have to live thru.. having decided to use VB:-)

--
To get a simple reference to the COM interface,
drop a user control ICMSPassword on a form. code is the sameas you have been doing:

dim objPLugin as ICMSPlugin
dim objpass as ICMSPassword.

set objPass = Form.ICMSPassword1
' here objPass is both a Usercontrol reference and also the Cominterface
set objPlugin = objPass ' is valid and COREECT also, if you ask me!!
' you dont need a CreateObject for ICMSPlugin, unless you want another instance/reference.
'
Debug.print objpass is Typeof ICMSPlugin
' will print true





if you want more tell me what exactly you want.. i do understand a bit of COM, i may be able to tell the VB way. What exacly you propose to do with the interface pointer of ICMSPassword?


RK

This is a beautiful explanation of the requirement.

It depends on how the frame work is returning the interface.
Something like this may still work:

dim objPass as ICMSPassowrd
dim objPlugin as ICMSPlugin

set objPlugin = CreateObject("Library.ICMSPassword")
'' ** NOTICE the Class. it is not PLUGIN
'' and this line is valid because ICMSPassword class created above supports plugin interface.
'' In your case, it may not be a direct CreateObject, but a Me.Controls.Add.. or whatever
''

if typeof objPlugin is ICMSPassword then
set objPass = objPlugin
end if

I just now did a small test and this is the code


private Sub Form_Load()
Dim ttt as ITest1
Dim ttt2 as ITest2 '<-- Implements Itest1 actually

set ttt = CreateObject("InterfaceTests.ITest2")
'' Notice the Class name it is Itest2

If TypeOf ttt is ITest2 then
set ttt2 = ttt
End If

set ttt = nothing
set ttt2 = nothing

set ttt = CreateThruFuncAsObject("InterfaceTests.ITest2")
If TypeOf ttt is ITest2 then
set ttt2 = ttt
End If

set ttt = nothing
set ttt2 = nothing


set ttt = CreateThruFuncAsClass("InterfaceTests.ITest2")
If TypeOf ttt is ITest2 then
set ttt2 = ttt
End If

set ttt = nothing
set ttt2 = nothing



End Sub

private Function CreateThruFuncAsObject(szClsName as string) as Object

set CreateThruFuncAsObject = CreateObject(szClsName)

End Function

private Function CreateThruFuncAsClass(szClsName as string) as InterfaceTests.ITest1
set CreateThruFuncAsClass = CreateObject(szClsName)
End Function






and it goes thru w/o a glitch and works

RK

The third example in your code is closest to what I'm doing. I'm calling a function and getting a ICMSPlugin back and I set it into a variable named objPlugin (Dim objPlugin as ICMSPlugin) (that's the interface my control implements). But when I check "TypeOf objPlugin is ICMSPassword" I get False even though the ICMSPlugin is an interface on an instance of a CMS_Security.ICMSPassword control which was created by the MDIChild form in the framework doing something like this (don't have the exact code in front of me but I remember what I was thinking when I wrote it... Sounds dangerous, huh?) :)
[vbcode]Dim objExt as VBControlExtender
Dim objPlugin as ICMSPlugin
Set objExt = me.Controls.add("CMS_Security.ICMSPassword)
Set objPlugin = objExt.Object
... objPlugin is returned to the caller.

I'm off to work this morning so I'll check back in throughout the day. :)

-----
Lee Perkins
TigerBase Technologies

unfortunately, i cannot create an example of your case, because i am still using VB 5.0!!

I will still see if i can simulate a case...

RK

any progress? or too busy trying ??

RK