Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Chriss Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

How to reference COM+

Status
Not open for further replies.

nigz

Programmer
Jun 15, 2001
60
GB
OK I have been looking into this now for a while - basically we have written an n-tier app VB6, COM+, SQL2000 but we are unsure which is the best way to reference objects. Advice seems to differ and alot of it appears to deal with MTS ratyher than COM+. So initiating a new com+ component from the client do I use:

set myObj = new myObj
set myObj = createobject(myobj) or
set myObj = createinstance(myObj) ????

and what about 1 component referencing another, & what about a component creating an object such as an ADODB.Recordset?

If someone could point me in the right direction it would be much appreciated - I am just confiused as to the reason why etc. Also if anyone could recommend any reading matter - most of the stuff I've seen deals mainly with MTS with a bit about COM+ at the end which just adds to the confusion.

TIA - Nigz
 
ObjectContext.CreateInstance("blah") is for MTS components being created from another MTS component where you want the new component to share the transaction of the calling component.

Best practice client side is the following if you know the class of the object at design time.

Dim cmyObj as myObject
Set cmyObj = New myObject
...

Never use the following

Dim cmyObj = New myObject

Tho this looks neater it forces VB6 to check if the object has been initialised yet on EVERY call to the object. This is because that line doesn't actually create the instance of the object. It sets it up that the object will get instantiated on the fly if it isn't already.

Thus this code would work (assuming you already have conn setup)

DIM rs as NEW ADODB.Recordset
rs.open "SELECT * FROM Clients",conn
do until rs.eof
...
loop
Set rs = nothing
rs.open "SELECT * FROM Invoices"
...

as for set myObj = createobject(myobj)
this is pretty much the same as "NEW" if the object is declared as the actual proper class type. Where you should
use this statement is if you didn't know what type of object you where going to be creating at design time. Thus the code might look like this

PUBLIC SUB Create_Object(sObjectName As String)
DIM tObj as Object
Set tObj = CreateObject(sObjectName)

...

END SUB

this code is slower executing than the code above where the object is declared with the proper class type then instanciated with the "NEW" key word. Using the "NEW" key word with properly declared class types causes "Early Binding" which uses V-Table Binding (think of these as pointers pointing directly to the public interfaces of your classes....because thats what it is 8). The later meathod can determine what class is going to be used at compile time thus VB has to do late binding and that means for every call to your object VB has to really make 2 calls to a hidden interface, to vb, called IUnknown.

So a statement like this

cmyObj.GetCustomer "John","Doe"

vb changes to this

i = cmyObj.GetIDofName "GetCustomer"
cmyObj.Invoke i, "John", "Doe"

In short use the

DIM rsClients AS ADODB.Recordset
SET rsClients = NEW ADODB.Recordset

method

Hope this helps
 
I agree with SemperFiDownUnda.... (0_0)

Additionally, CreateInstance is used for context wrapping. Com+, however; has an enhanced way of implementing the context wrappping.

For me, the safest way to reference an object is through CreateObject...

hope this helps.....
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top