CreateObject question...

OK. I have used CreateObject many times in COM+ programming.
But...I now have a standard EXE that has some classes inside it, no external DLL.
How do I use CreateObject to create a class??

VB Code:

Dim objWoof As MyClass
   Set objWoof = CreateObject("MyClass")

Doesn't work...ActiveX EXE cannot create object error...

What am I doing wrong?

Woof

Set objWoof = New MyClass

Or am I missing something here?

Yes, that should work. If I'm not mistaken, the CreateObject function is for registered classes.

shouldn't that be:

VB Code:

Dim objWoof As MyClass
   Set objWoof = CreateObject("Application.MyClass")

:confused:

either that or listen to the frog ;)

Yes...I want to use the create object:

VB Code:

Private Sub cmdClickMe_Click()
Dim objNew      As clsCommon
Dim strClass    As String
    Select Case GetSelectedOption
        Case OPT_COMPONENT
            strClass = "clsComponent"
        Case OPT_SERVER
            strClass = "clsServer"
        Case OPT_DBASE
            strClass = "clsDBase"
        Case OPT_NONE
            MsgBox "No option selected", vbInformation
    End Select
    If Not (strClass = vbNullString) Then
        Set objNew = CreateObject(strClass)
        objNew.OptButton = "Fish"
        objNew.AddChanges
        Set objNew = Nothing
    End If
End Sub

Where clsCommon is IMPLEMENTED in the other classes.
I can do:

VB Code:

Dim objNew As clsCommon
   Set objNew = New clsComponent

U see what I'm trying to do?

Woof

Quote:

---

Originally posted by si_the_geek
shouldn't that be:

VB Code:

Dim objWoof As MyClass
   Set objWoof = CreateObject("Application.MyClass")

:confused:

either that or listen to the frog ;)

---

Same error :(
Doesn't work...Boooooooooo

I hate to admitt it, but the Frog may be right :(

Quote:

---

Originally posted by Wokawidget


I hate to admitt it, but the Frog may be right

---

Thanks for the vote of confidence. :cry:



Isn't there a call command function of some sort which can evaluate those 'strings' for you? I'm sure you know what I'm talking about. I don't know the name of the function though.

Why don't you declare the variable as an object and then set the object. For example

VB Code:

Dim MyVar as Object
     Set MyVar = CreateObject("MyClass")
 
'or even better
 
     Set MyVar = CreateObject("AppName.MyClass")

I found while doing some Multithreading that if you declare the variable first as an Object and then using CreateObject with the name of the class fully typed out that VB is much happier.

Now if you are using an External ActiveX DLL then you might try the sattelite approach where you explicitly call one dll with the new and then reset it using the CreateObject function for example:

VB Code:

Public MyVar as New Application000.CLang
     Set MyVar = CreateObject("Application001.CLang")

Doesn't work.
The frog is almost certainly right regarding the CreateObject function.
There is no need to Dim the varible as an object, unless u are not directly referencing the external DLL in your project.

All my code and classes are in one standard EXE...that's the problem...however...being being thick and all, I overlooked something:

VB Code:

Private Sub cmdClickMe_Click()
Dim objNew      As clsCommon
    Select Case GetSelectedOption
        Case OPT_COMPONENT
            Set objNew = New clsComponent
        Case OPT_SERVER
            Set objNew = New clsServer
        Case OPT_DBASE
            Set objNew = New clsDBase
        Case OPT_NONE
            MsgBox "No option selected", vbInformation
    End Select
    If Not (objNew Is Nothing) Then
        objNew.OptButton = txtOption
        objNew.AddChanges
        Set objNew = Nothing
    End If
End Sub

:D
D'oh!
Why didn't I think of that before...

Roooaaaarrrrrr

Quote:

---

Originally posted by mendhak
Thanks for the vote of confidence. :cry:

---

Awwwww...there there :)

Quote:

---

Originally posted by Wokawidget
Doesn't work.
The frog is almost certainly right regarding the CreateObject function.

---

The frog is ALWAYS right. The frog makes all the rules!

Quote:

---

VB Code:

Private Sub cmdClickMe_Click()
Dim objNew      As clsCommon
    Select Case GetSelectedOption
        Case OPT_COMPONENT
            Set objNew = New clsComponent
        Case OPT_SERVER
            Set objNew = New clsServer
        Case OPT_DBASE
            Set objNew = New clsDBase
        Case OPT_NONE
            MsgBox "No option selected", vbInformation
    End Select
    If Not (objNew Is Nothing) Then
        objNew.OptButton = txtOption
        objNew.AddChanges
        Set objNew = Nothing
    End If
End Sub

:D
D'oh!

---

Here's your sign... :D

This is the situation:

CreateObject uses the COM+ subsystem to create components
New uses the VB runtime system to create components.

If you declare a class inside a standard EXE no type library will be generated so COM+ cannot determine how to create the proxy/stub stuff. The class cannot be created using CreateObject; you will certainly need to use 'New' Besides 'New' is always faster.

However if you create a COM+ DLL (so it's hosted inside COM+- dllhost.exe) you shouldn't use the 'New' method to instantiate classes from the same project (DLL) This is because the VB runtime will instantiate the class, and not COM+; in this scenario you would want COM+ to create the object as this will ensure proper JIT activation, and garbage collection.

However, if you want to create an object in a different DLL, you can use New because the VB runtime will defer the creation to COM+ (so it's effectively like CreateObject, but faster)

So, in your scenario, you will need to use New (as you are using Implements shouldn't you be creating seperate components for this anyway?)

My suggestion is to create your components inside a seperate DLL which gives you the architectural choice of doing what you please. Coding to 'get around' a specific problem (when in fact your initial code is entirely good practice) seems to me to be wrong. Sorry Frog.

Hope this helps.

Quote:

---

Originally posted by yrwyddfa
..to me to be wrong. Sorry Frog.

---

Eh? :confused:

I agree with you. What gives? :p

Unless I'm mistaken you're encouraging the use of 'New' to avoid the CreateObject problem.

Perhaps.

Then again, maybe not.

So, I have a DLL, BadgerDLL, running under MTS/COmponent Services. This DLL has 2 classes - Woof and Growl.

My Client UI app creates an instance of Woof using:

VB Code:

Dim objSausage As Woof
   Set objSausage = New Woof

That is correct?

Now what you are saying is that if my class woof creates an instance of Growl then it SHOULD NOT use the NEW statement, but instead use CreateObject, as in:

VB Code:

'In class woof
Dim objSausage As Growl
   Set objSausage = New Growl 'BAD BAD! NO! Bad Badger *SLAP*
   Set objSausage = CreateObject("BadgerDLL.Growl") 'this good yes?

Am I right here?

Woka

That is correct.

Now I didn't know that...:D
Is it advisable to use this even if the DLL is not running under MTS?

Woka

It might be helpful if I fully explain what is going on.

This only applies (I think to COM+)

All configured components; that is those which are loaded into COM+ actually execute in a process called dllhost.exe - unfortunately most people who have come across this file have come across it with an MSBlast variant.

So all of your calls to this component (from another COM+ component, or other exe) are cross-process calls - which we all know are expensive and generally bad.

COM will help this process efficiently - VB will not. The part of COM that helps with the object activation (ie creation and destruction) is called the Service Control Manager. What happens is that the SCM will load an instance of your object (after it's first request) so that your object is always loaded inside DLLHOST.exe. COM+ will then manage this instance. If you maintain any form of state across function calls COM will create a new object for you (to maintain that state - but remember you only have 8 threads of execution +n processors so you can only safely have 8 stateful COM object instances at any one time. If you have more the threads are shared in a roundrobin fashion - the axiom here is that any COM component should not maintain any state across function calls - a technique which, infortunately, is alien to most programmers especially C++ ones. This is why most C++ programmers do not have COM on their CV's)

When you use 'New' or 'CreateObject' VB knows just about enough to make a call to a function called CoCreateInstance which instantiates tells the SCM to create the object (it gets the rest of the relevant information from registry entries) with the following issues . . .

If you use 'New' and the object that you want to create lives in a seperate DLL then all is fine - the call is sent to the SCM, and COM will manage this on your behalf - properly.

If you use 'New' and the object that you want to create lives in the same DLL then the VB runtime creates and binds the object on it's own without any help from the SCM. Even worse, the object is never created properly and the COM+ runtime doesn't even know that it exists; so it can never be managed properly. Bear in mind that VB is the ultimate COM component, so operating correctly with the SCM is of utmost importance.

Hope this helps a little . . .

To answer your question: CreateObject is always safe but always slower (it will go to the registry to look up the information) If you know the issues surrounding 'New' you can use your judgement to choose which one to use.