microsoft.public.cert.exam.mcsd - Difference between CreateObject() and Set object = ...?

Author

Difference between CreateObject() and Set object = ...?

Daniel Doyle

2002-10-08, 6:23 am

Hello, I am looking to take the VB6 tests at some point in the near future
(and then try to move onto .NET).
However, I just have this niggling question in my mind. When to use...

object = CreateObject()
and
Set object = New...

They seem to be used interchangeably but I would like to know the difference
between them (if any), and in what situation would each be used? Also, is
GetObject() the same as Set object = ... (without the New)?
I know that CreateObject and GetObject are used in VBScript - but is this
their only real purpose?
It seems like such a basic thing, but it is causing me a little confusion.

Thank you. Dan.

Mike Hohenshilt

2002-10-08, 12:23 pm

First off, for both cases, you need to use the Set keyword using New or
CreateObject.

CreateObject is used for late binding, and New is for early binding.

What is this binding? If the VB compiler knows what objects you are working
with (ie. you have made references to them), you can use early binding.
What happens is the compiler produces code that will access the object's
properties and methodes directly. Late binding is when the compiler doesn't
know how to access the object directly, so I needs to use COM specific
methodes that will figure it out. In the end both early and late binding
will produce the same results. Late binding, because of the overhead, is a
bit slower.

I think that about sums it up. I think those COM methods are part of the
IDispatch interface, not sure though.

"Daniel Doyle" <daniel.no_spamdoyle@ukf.net> wrote in message
news:OEZcnrrbCHA.1940@tkmsftngp11...
> Hello, I am looking to take the VB6 tests at some point in the near future
> (and then try to move onto .NET).
> However, I just have this niggling question in my mind. When to use...
>
> object = CreateObject()
> and
> Set object = New...
>
> They seem to be used interchangeably but I would like to know the
difference
> between them (if any), and in what situation would each be used? Also, is
> GetObject() the same as Set object = ... (without the New)?
> I know that CreateObject and GetObject are used in VBScript - but is this
> their only real purpose?
> It seems like such a basic thing, but it is causing me a little confusion.
>
> Thank you. Dan.
>
>

Daniel Doyle

2002-10-09, 3:23 am

Thanks for the reply. Does this mean that you can create an instance that
you do not have a reference to using CreateObject? I understand that you can
late bind by dimensioning an object variable as 'Object' rather than the
specific object you intend to use. However, my understanding is that when
you do the following,

Set objectvariable = New Object
Set objectvariable = actualobject

you would need to have reference to the class of the actual object before
you can use it's properties and methods. Does using CreateObject mean that
you do not need to explicitly reference the object's class?

The other source of my confusion, is to whether

Set objectvariable = actualobject (without the New)
is the same as
Set objectvariable = GetObject(path, class)

Can GetObject do this without needing to reference the object class at
design time?

Thank you for your help. Dan.

"Mike Hohenshilt" <hohensm@hotmail.com> wrote in message
news:#kLNpyubCHA.4208@tkmsftngp08...
> First off, for both cases, you need to use the Set keyword using New or
> CreateObject.
>
> CreateObject is used for late binding, and New is for early binding.
>
> What is this binding? If the VB compiler knows what objects you are
working
> with (ie. you have made references to them), you can use early binding.
> What happens is the compiler produces code that will access the object's
> properties and methodes directly. Late binding is when the compiler
doesn't
> know how to access the object directly, so I needs to use COM specific
> methodes that will figure it out. In the end both early and late binding
> will produce the same results. Late binding, because of the overhead, is
a
> bit slower.
>
> I think that about sums it up. I think those COM methods are part of the
> IDispatch interface, not sure though.
>
>
> "Daniel Doyle" <daniel.no_spamdoyle@ukf.net> wrote in message
> news:OEZcnrrbCHA.1940@tkmsftngp11...
> > Hello, I am looking to take the VB6 tests at some point in the near
future
> > (and then try to move onto .NET).
> > However, I just have this niggling question in my mind. When to use...
> >
> > object = CreateObject()
> > and
> > Set object = New...
> >
> > They seem to be used interchangeably but I would like to know the
> difference
> > between them (if any), and in what situation would each be used? Also,
is
> > GetObject() the same as Set object = ... (without the New)?
> > I know that CreateObject and GetObject are used in VBScript - but is
this
> > their only real purpose?
> > It seems like such a basic thing, but it is causing me a little
confusion.
> >
> > Thank you. Dan.
> >
> >
>
>

D Weeks

2002-10-09, 6:23 am

Well, hopefully this will explain it... but it will take a few minutes.

To really, REALLY understand what the differences are, you need to
understand a bit more about something called Interfaces. VB programmers
typically use the default interface that VB creates for them automatcially.
It doesn't have to be that way. You can actually create the interface (for
example) as a Type Library File, then implement that interface in the DLL.
Let's say for a moment you've done that. You have a Type Library File (TLB)
called VehicleInterface.TLB. It exposes an interface called IVehicle. You
have a DLL called Vehicles.DLL that includes a class called Car. Car
implements the interface exposed in the TLB.

There are now two ways to create an instance of a car.

IF you have a reference set to the TLB AND the DLL:
Dim MyCar as VehicleInterface.IVehicle
Set MyCar = New Vehicles.Car

If you have a reference set to the TLB ONLY.
Dim MyCar as VehicleInterface.IVehicle
Set MyCar = CreateObject("Vehicles.Car")

Now, many VB programmers don't use TLBs or separate interfaces. They simply
DIM and SET to the createable class in the DLL. In that case...
Dim MyCar as Vehicles.Car
Set MyCar = New Vehicles.Car

and

Dim MyCar as Vehicles.Car
Set MyCar = CreateObject("Vehicles.Car")

DO the same thing, but the second example runs a little slower.

And any of these would work if you changed the Dim statement to use the
generic Object variable (Dim MyCar as Object). But this will make your
program REMARKABLY slower AND lose your intellisense in design time.
(Remember, intellisense is inabled by the DIM statement knowing exactly what
you're creating.)

So, the key here is this: to use the New keyword, the client MUST have a
reference set to the DLL. (Because, it MUST know the Globally Unique
IDentifier or GUID of the class. It uses that GUID to tell the registry
what type of object to create.) If the client does NOT have a reference to
the creatable object class in the DLL, it does NOT have the GUID.
Therefore, it uses CreateObject and gives it the Program ID (ProgID) of the
class. The client then uses the ProgID instead of the GUID to track down
the class.

GetObject is only used if instead of creating a new instance of the object
type, you want to open an existing object. For example, if you've saved a
Word document, and now - through VB - you want to open that document in
Word. You could do NEW, but that starts a new instance of Word, then you'd
have to figure out how to do a file open and such. OR, you could do a
GetObject on the document you want to open, and it opens that specific
document in Word.

Now, on to the next question...

Dim MyCar as Vehicels.Car
Set MyCar = New Vehicles.Car

and

Dim MyCar as New Vehicles.Car

definitely do NOT do the same thing. In the first example, the DIM
statement creates a variable called MyCar, and "turns on" intellisense. The
SET statement actually creates the object. Now, you are ready to invoke the
methods of the object. In the second example, the single line of code
simply creates the variable and "turns on" intellisense. If you now invoke
a method of the object, VB essentially says, "Have we created that object
yet? Because if so, I need to invoke this method. If not, let's create it
'on the fly' and invoke this method." Fine... but it's going to do that
"check to see if it exists" routine with EVERY call to a method that you
make. There are other "issues" with this, but this is the big one. It is
extremely ineffecient, since every method call now includes an extra step,
so most VB programmers avoid it. (By the way, in VB.NET they've "fixed
this" so both of the these examples work like the first one.)

I hope all of this helps.

dw

"Daniel Doyle" <daniel.no_spamdoyle@ukf.net> wrote in message
news:#Wbclx2bCHA.1940@tkmsftngp11...
> Thanks for the reply. Does this mean that you can create an instance that
> you do not have a reference to using CreateObject? I understand that you
can
> late bind by dimensioning an object variable as 'Object' rather than the
> specific object you intend to use. However, my understanding is that when
> you do the following,
>
> Set objectvariable = New Object
> Set objectvariable = actualobject
>
> you would need to have reference to the class of the actual object before
> you can use it's properties and methods. Does using CreateObject mean that
> you do not need to explicitly reference the object's class?
>
> The other source of my confusion, is to whether
>
> Set objectvariable = actualobject (without the New)
> is the same as
> Set objectvariable = GetObject(path, class)
>
> Can GetObject do this without needing to reference the object class at
> design time?
>
> Thank you for your help. Dan.
>
> "Mike Hohenshilt" <hohensm@hotmail.com> wrote in message
> news:#kLNpyubCHA.4208@tkmsftngp08...
> > First off, for both cases, you need to use the Set keyword using New or
> > CreateObject.
> >
> > CreateObject is used for late binding, and New is for early binding.
> >
> > What is this binding? If the VB compiler knows what objects you are
> working
> > with (ie. you have made references to them), you can use early binding.
> > What happens is the compiler produces code that will access the object's
> > properties and methodes directly. Late binding is when the compiler
> doesn't
> > know how to access the object directly, so I needs to use COM specific
> > methodes that will figure it out. In the end both early and late
binding
> > will produce the same results. Late binding, because of the overhead,
is
> a
> > bit slower.
> >
> > I think that about sums it up. I think those COM methods are part of
the
> > IDispatch interface, not sure though.
> >
> >
> > "Daniel Doyle" <daniel.no_spamdoyle@ukf.net> wrote in message
> > news:OEZcnrrbCHA.1940@tkmsftngp11...
> > > Hello, I am looking to take the VB6 tests at some point in the near
> future
> > > (and then try to move onto .NET).
> > > However, I just have this niggling question in my mind. When to use...
> > >
> > > object = CreateObject()
> > > and
> > > Set object = New...
> > >
> > > They seem to be used interchangeably but I would like to know the
> > difference
> > > between them (if any), and in what situation would each be used? Also,
> is

> > > GetObject() the same as Set object = ... (without the New)?
> > > I know that CreateObject and GetObject are used in VBScript - but is
> this
> > > their only real purpose?
> > > It seems like such a basic thing, but it is causing me a little
> confusion.
> > >
> > > Thank you. Dan.
> > >
> > >
> >
> >
>
>

Daniel Doyle

2002-10-09, 7:23 am

Thanks for spending time on the detail of your reply - this the type of
answer I love to see as I feel it gives real insight into something that, at
first glance, seems quite straightforward.
I understand the differences now, but will be doing more research as there
does seem to be a lot more I can learn - just on this small topic alone - in
order to gain a more complete understanding of how vb works.

Thanks again. Dan.

"D Weeks" <dweeks@NOSPAMmchsi.com> wrote in message
news:egsKbJ4bCHA.2420@tkmsftngp09...
> Well, hopefully this will explain it... but it will take a few minutes.
>
> To really, REALLY understand what the differences are, you need to
> understand a bit more about something called Interfaces. VB programmers
> typically use the default interface that VB creates for them
automatcially.
> It doesn't have to be that way. You can actually create the interface
(for
> example) as a Type Library File, then implement that interface in the DLL.
> Let's say for a moment you've done that. You have a Type Library File
(TLB)
> called VehicleInterface.TLB. It exposes an interface called IVehicle.
You
> have a DLL called Vehicles.DLL that includes a class called Car. Car
> implements the interface exposed in the TLB.
>
> There are now two ways to create an instance of a car.
>
> IF you have a reference set to the TLB AND the DLL:
> Dim MyCar as VehicleInterface.IVehicle
> Set MyCar = New Vehicles.Car
>
> If you have a reference set to the TLB ONLY.
> Dim MyCar as VehicleInterface.IVehicle
> Set MyCar = CreateObject("Vehicles.Car")
>
> Now, many VB programmers don't use TLBs or separate interfaces. They
simply
> DIM and SET to the createable class in the DLL. In that case...
> Dim MyCar as Vehicles.Car
> Set MyCar = New Vehicles.Car
>
> and
>
> Dim MyCar as Vehicles.Car
> Set MyCar = CreateObject("Vehicles.Car")
>
> DO the same thing, but the second example runs a little slower.
>
> And any of these would work if you changed the Dim statement to use the
> generic Object variable (Dim MyCar as Object). But this will make your
> program REMARKABLY slower AND lose your intellisense in design time.
> (Remember, intellisense is inabled by the DIM statement knowing exactly
what
> you're creating.)
>
> So, the key here is this: to use the New keyword, the client MUST have a
> reference set to the DLL. (Because, it MUST know the Globally Unique
> IDentifier or GUID of the class. It uses that GUID to tell the registry
> what type of object to create.) If the client does NOT have a reference
to
> the creatable object class in the DLL, it does NOT have the GUID.
> Therefore, it uses CreateObject and gives it the Program ID (ProgID) of
the
> class. The client then uses the ProgID instead of the GUID to track down
> the class.
>
> GetObject is only used if instead of creating a new instance of the object
> type, you want to open an existing object. For example, if you've saved a
> Word document, and now - through VB - you want to open that document in
> Word. You could do NEW, but that starts a new instance of Word, then
you'd
> have to figure out how to do a file open and such. OR, you could do a
> GetObject on the document you want to open, and it opens that specific
> document in Word.
>
> Now, on to the next question...
>
> Dim MyCar as Vehicels.Car
> Set MyCar = New Vehicles.Car
>
> and
>
> Dim MyCar as New Vehicles.Car
>
> definitely do NOT do the same thing. In the first example, the DIM
> statement creates a variable called MyCar, and "turns on" intellisense.
The
> SET statement actually creates the object. Now, you are ready to invoke
the
> methods of the object. In the second example, the single line of code
> simply creates the variable and "turns on" intellisense. If you now
invoke
> a method of the object, VB essentially says, "Have we created that object
> yet? Because if so, I need to invoke this method. If not, let's create
it
> 'on the fly' and invoke this method." Fine... but it's going to do that
> "check to see if it exists" routine with EVERY call to a method that you
> make. There are other "issues" with this, but this is the big one. It is
> extremely ineffecient, since every method call now includes an extra step,
> so most VB programmers avoid it. (By the way, in VB.NET they've "fixed
> this" so both of the these examples work like the first one.)
>
> I hope all of this helps.
>
> dw
>
>
> "Daniel Doyle" <daniel.no_spamdoyle@ukf.net> wrote in message
> news:#Wbclx2bCHA.1940@tkmsftngp11...
> > Thanks for the reply. Does this mean that you can create an instance
that
> > you do not have a reference to using CreateObject? I understand that you
> can
> > late bind by dimensioning an object variable as 'Object' rather than the
> > specific object you intend to use. However, my understanding is that
when
> > you do the following,
> >
> > Set objectvariable = New Object
> > Set objectvariable = actualobject
> >
> > you would need to have reference to the class of the actual object
before
> > you can use it's properties and methods. Does using CreateObject mean
that
> > you do not need to explicitly reference the object's class?
> >
> > The other source of my confusion, is to whether
> >
> > Set objectvariable = actualobject (without the New)
> > is the same as
> > Set objectvariable = GetObject(path, class)
> >
> > Can GetObject do this without needing to reference the object class at
> > design time?
> >
> > Thank you for your help. Dan.
> >
> > "Mike Hohenshilt" <hohensm@hotmail.com> wrote in message
> > news:#kLNpyubCHA.4208@tkmsftngp08...
> > > First off, for both cases, you need to use the Set keyword using New
or[co
lor=darkred]
> > > CreateObject.
> > >
> > > CreateObject is used for late binding, and New is for early binding.
> > >
> > > What is this binding? If the VB compiler knows what objects you are
> > working
> > > with (ie. you have made references to them), you can use early[/color]
binding. [colo
r=darkred]
> > > What happens is the compiler produces code that will access the[/color]
object's
> > > properties and methodes directly. Late binding is when the compiler
> > doesn't
> > > know how to access the object directly, so I needs to use COM specific
> > > methodes that will figure it out. In the end both early and late
> binding
> > > will produce the same results. Late binding, because of the overhead,
> is
> > a
> > > bit slower.
> > >
> > > I think that about sums it up. I think those COM methods are part of
> the
> > > IDispatch interface, not sure though.
> > >
> > >
> > > "Daniel Doyle" <daniel.no_spamdoyle@ukf.net> wrote in message
> > > news:OEZcnrrbCHA.1940@tkmsftngp11...
> > > > Hello, I am looking to take the VB6 tests at some point in the near
> > future
> > > > (and then try to move onto .NET).
> > > > However, I just have this niggling question in my mind. When to
use... [colo
r=darkred]
> > > >
> > > > object = CreateObject()
> > > > and
> > > > Set object = New...
> > > >
> > > > They seem to be used interchangeably but I would like to know the
> > > difference
> > > > between them (if any), and in what situation would each be used?[/color]
Also,

> > is
> > > > GetObject() the same as Set object = ... (without the New)?
> > > > I know that CreateObject and GetObject are used in VBScript - but is
> > this
> > > > their only real purpose?
> > > > It seems like such a basic thing, but it is causing me a little
> > confusion.
> > > >
> > > > Thank you. Dan.
> > > >
> > > >
> > >
> > >
> >
> >
>
>

Daniel Joskovski

2002-10-09, 5:23 pm

You do great job, but sorry, I think you miss the point, let me explain what
I think.
Question was When to use New and when to use CreateObject? Answer is use NEW
when your component support that keyword, some ActiveX Servers and older
COM-s don't support NEW keyword (word < 7.0, Excel < 8.0) if you want to use
them CreateObject is only choice. Sorry for my English, I hope this help.
Regards,
Daniel

"Daniel Doyle" <daniel.no_spamdoyle@ukf.net> wrote in message
news:OE47Yk4bCHA.2556@tkmsftngp09...
> Thanks for spending time on the detail of your reply - this the type of
> answer I love to see as I feel it gives real insight into something that,
at
> first glance, seems quite straightforward.
> I understand the differences now, but will be doing more research as there
> does seem to be a lot more I can learn - just on this small topic alone -
in
> order to gain a more complete understanding of how vb works.
>
> Thanks again. Dan.
>
> "D Weeks" <dweeks@NOSPAMmchsi.com> wrote in message
> news:egsKbJ4bCHA.2420@tkmsftngp09...
> > Well, hopefully this will explain it... but it will take a few minutes.
> >
> > To really, REALLY understand what the differences are, you need to
> > understand a bit more about something called Interfaces. VB programmers
> > typically use the default interface that VB creates for them
> automatcially.
> > It doesn't have to be that way. You can actually create the interface
> (for
> > example) as a Type Library File, then implement that interface in the
DLL.
> > Let's say for a moment you've done that. You have a Type Library File
> (TLB)
> > called VehicleInterface.TLB. It exposes an interface called IVehicle.
> You
> > have a DLL called Vehicles.DLL that includes a class called Car. Car
> > implements the interface exposed in the TLB.
> >
> > There are now two ways to create an instance of a car.
> >
> > IF you have a reference set to the TLB AND the DLL:
> > Dim MyCar as VehicleInterface.IVehicle
> > Set MyCar = New Vehicles.Car
> >
> > If you have a reference set to the TLB ONLY.
> > Dim MyCar as VehicleInterface.IVehicle
> > Set MyCar = CreateObject("Vehicles.Car")
> >
> > Now, many VB programmers don't use TLBs or separate interfaces. They
> simply
> > DIM and SET to the createable class in the DLL. In that case...
> > Dim MyCar as Vehicles.Car
> > Set MyCar = New Vehicles.Car
> >
> > and
> >
> > Dim MyCar as Vehicles.Car
> > Set MyCar = CreateObject("Vehicles.Car")
> >
> > DO the same thing, but the second example runs a little slower.
> >
> > And any of these would work if you changed the Dim statement to use the
> > generic Object variable (Dim MyCar as Object). But this will make your
> > program REMARKABLY slower AND lose your intellisense in design time.
> > (Remember, intellisense is inabled by the DIM statement knowing exactly
> what
> > you're creating.)
> >
> > So, the key here is this: to use the New keyword, the client MUST have
a
> > reference set to the DLL. (Because, it MUST know the Globally Unique
> > IDentifier or GUID of the class. It uses that GUID to tell the registry
> > what type of object to create.) If the client does NOT have a reference
> to
> > the creatable object class in the DLL, it does NOT have the GUID.
> > Therefore, it uses CreateObject and gives it the Program ID (ProgID) of
> the
> > class. The client then uses the ProgID instead of the GUID to track
down
> > the class.
> >
> > GetObject is only used if instead of creating a new instance of the
object
> > type, you want to open an existing object. For example, if you've saved
a
> > Word document, and now - through VB - you want to open that document in
> > Word. You could do NEW, but that starts a new instance of Word, then
> you'd
> > have to figure out how to do a file open and such. OR, you could do a
> > GetObject on the document you want to open, and it opens that specific
> > document in Word.
> >
> > Now, on to the next question...
> >
> > Dim MyCar as Vehicels.Car
> > Set MyCar = New Vehicles.Car
> >
> > and
> >
> > Dim MyCar as New Vehicles.Car
> >
> > definitely do NOT do the same thing. In the first example, the DIM
> > statement creates a variable called MyCar, and "turns on" intellisense.
> The
> > SET statement actually creates the object. Now, you are ready to invoke
> the
> > methods of the object. In the second example, the single line of code
> > simply creates the variable and "turns on" intellisense. If you now
> invoke
> > a method of the object, VB essentially says, "Have we created that
object
> > yet? Because if so, I need to invoke this method. If not, let's create
> it
> > 'on the fly' and invoke this method." Fine... but it's going to do that
> > "check to see if it exists" routine with EVERY call to a method that you
> > make. There are other "issues" with this, but this is the big one. It
is
> > extremely ineffecient, since every method call now includes an extra
step,

> > so most VB programmers avoid it. (By the way, in VB.NET they've "fixed
> > this" so both of the these examples work like the first one.)
> >
> > I hope all of this helps.
> >
> > dw
> >
> >
> > "Daniel Doyle" <daniel.no_spamdoyle@ukf.net> wrote in message
> > news:#Wbclx2bCHA.1940@tkmsftngp11...
> > > Thanks for the reply. Does this mean that you can create an instance
> that
> > > you do not have a reference to using CreateObject? I understand that
you
> > can
> > > late bind by dimensioning an object variable as 'Object' rather than
the[c
olor=darkred]
> > > specific object you intend to use. However, my understanding is that
> when
> > > you do the following,
> > >
> > > Set objectvariable = New Object
> > > Set objectvariable = actualobject
> > >
> > > you would need to have reference to the class of the actual object
> before
> > > you can use it's properties and methods. Does using CreateObject mean
> that
> > > you do not need to explicitly reference the object's class?
> > >
> > > The other source of my confusion, is to whether
> > >
> > > Set objectvariable = actualobject (without the New)
> > > is the same as
> > > Set objectvariable = GetObject(path, class)
> > >
> > > Can GetObject do this without needing to reference the object class at
> > > design time?
> > >
> > > Thank you for your help. Dan.
> > >
> > > "Mike Hohenshilt" <hohensm@hotmail.com> wrote in message
> > > news:#kLNpyubCHA.4208@tkmsftngp08...
> > > > First off, for both cases, you need to use the Set keyword using[/color]
New
> or

> > > > CreateObject.
> > > >
> > > > CreateObject is used for late binding, and New is for early binding.
> > > >
> > > > What is this binding? If the VB compiler knows what objects you are
> > > working
> > > > with (ie. you have made references to them), you can use early
> binding.
> > > > What happens is the compiler produces code that will access the
> object's
> > > > properties and methodes directly. Late binding is when the compiler
> > > doesn't
> > > > know how to access the object directly, so I needs to use COM
specific
> > > > methodes that will figure it out. In the end both early and late
> > binding
> > > > will produce the same results. Late binding, because of the
overhead,
> > is
> > > a
> > > > bit slower.
> > > >
> > > > I think that about sums it up. I think those COM methods are part
of
> > the
> > > > IDispatch interface, not sure though.
> > > >
> > > >
> > > > "Daniel Doyle" <daniel.no_spamdoyle@ukf.net> wrote in message
> > > > news:OEZcnrrbCHA.1940@tkmsftngp11...
> > > > > Hello, I am looking to take the VB6 tests at some point in the
near[
color=darkred]
> > > future
> > > > > (and then try to move onto .NET).
> > > > > However, I just have this niggling question in my mind. When to
> use...
> > > > >
> > > > > object = CreateObject()
> > > > > and
> > > > > Set object = New...
> > > > >
> > > > > They seem to be used interchangeably but I would like to know the
> > > > difference
> > > > > between them (if any), and in what situation would each be used?
> Also,
> > > is
> > > > > GetObject() the same as Set object = ... (without the New)?
> > > > > I know that CreateObject and GetObject are used in VBScript - but[/color]
is[co
lor=darkred]
> > > this
> > > > > their only real purpose?
> > > > > It seems like such a basic thing, but it is causing me a little
> > > confusion.
> > > > >
> > > > > Thank you. Dan.
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>[/color]

D Weeks

2002-10-09, 7:23 pm

Thanks for adding to my response. I wasn't even thinking of it this way.
What you say is definitely true. But I understood the original question to
be more of a "when both work, they seem to do the same thing. Are they?"
And they are definitely not.

dw

"Daniel Joskovski" <omnis@unet.com.mk> wrote in message
news:#d3Gfw9bCHA.1520@tkmsftngp08...
> You do great job, but sorry, I think you miss the point, let me explain
what
> I think.
> Question was When to use New and when to use CreateObject? Answer is use
NEW
> when your component support that keyword, some ActiveX Servers and older
> COM-s don't support NEW keyword (word < 7.0, Excel < 8.0) if you want to
use
> them CreateObject is only choice. Sorry for my English, I hope this help.
> Regards,
> Daniel
>
> "Daniel Doyle" <daniel.no_spamdoyle@ukf.net> wrote in message
> news:OE47Yk4bCHA.2556@tkmsftngp09...
> > Thanks for spending time on the detail of your reply - this the type of
> > answer I love to see as I feel it gives real insight into something
that,
> at
> > first glance, seems quite straightforward.
> > I understand the differences now, but will be doing more research as
there

> > does seem to be a lot more I can learn - just on this small topic
alone -
> in
> > order to gain a more complete understanding of how vb works.
> >
> > Thanks again. Dan.
> >
> > "D Weeks" <dweeks@NOSPAMmchsi.com> wrote in message
> > news:egsKbJ4bCHA.2420@tkmsftngp09...
> > > Well, hopefully this will explain it... but it will take a few
minutes. [colo
r=darkred]
> > >
> > > To really, REALLY understand what the differences are, you need to
> > > understand a bit more about something called Interfaces. VB[/color]
programmers
> > > typically use the default interface that VB creates for them
> > automatcially.
> > > It doesn't have to be that way. You can actually create the interface
> > (for
> > > example) as a Type Library File, then implement that interface in the
> DLL.
> > > Let's say for a moment you've done that. You have a Type Library File

> > (TLB)
> > > called VehicleInterface.TLB. It exposes an interface called IVehicle.
> > You
> > > have a DLL called Vehicles.DLL that includes a class called Car. Car
> > > implements the interface exposed in the TLB.
> > >
> > > There are now two ways to create an instance of a car.
> > >
> > > IF you have a reference set to the TLB AND the DLL:
> > > Dim MyCar as VehicleInterface.IVehicle
> > > Set MyCar = New Vehicles.Car
> > >
> > > If you have a reference set to the TLB ONLY.
> > > Dim MyCar as VehicleInterface.IVehicle
> > > Set MyCar = CreateObject("Vehicles.Car")
> > >
> > > Now, many VB programmers don't use TLBs or separate interfaces. They
> > simply
> > > DIM and SET to the createable class in the DLL. In that case...
> > > Dim MyCar as Vehicles.Car
> > > Set MyCar = New Vehicles.Car
> > >
> > > and
> > >
> > > Dim MyCar as Vehicles.Car
> > > Set MyCar = CreateObject("Vehicles.Car")
> > >
> > > DO the same thing, but the second example runs a little slower.
> > >
> > > And any of these would work if you changed the Dim statement to use
the[c
olor=darkred]
> > > generic Object variable (Dim MyCar as Object). But this will make[/color]
your[
color=darkred]
> > > program REMARKABLY slower AND lose your intellisense in design time.
> > > (Remember, intellisense is inabled by the DIM statement knowing[/color]
exactly
> > what
> > > you're creating.)
> > >
> > > So, the key here is this: to use the New keyword, the client MUST
have
> a
> > > reference set to the DLL. (Because, it MUST know the Globally Unique
> > > IDentifier or GUID of the class. It uses that GUID to tell the
registry
> > > what type of object to create.) If the client does NOT have a
reference
> > to
> > > the creatable object class in the DLL, it does NOT have the GUID.
> > > Therefore, it uses CreateObject and gives it the Program ID (ProgID)
of
> > the
> > > class. The client then uses the ProgID instead of the GUID to track
> down
> > > the class.
> > >
> > > GetObject is only used if instead of creating a new instance of the
> object
> > > type, you want to open an existing object. For example, if you've
saved
> a
> > > Word document, and now - through VB - you want to open that document
in[co
lor=darkred]
> > > Word. You could do NEW, but that starts a new instance of Word, then
> > you'd
> > > have to figure out how to do a file open and such. OR, you could do a
> > > GetObject on the document you want to open, and it opens that specific
> > > document in Word.
> > >
> > > Now, on to the next question...
> > >
> > > Dim MyCar as Vehicels.Car
> > > Set MyCar = New Vehicles.Car
> > >
> > > and
> > >
> > > Dim MyCar as New Vehicles.Car
> > >
> > > definitely do NOT do the same thing. In the first example, the DIM
> > > statement creates a variable called MyCar, and "turns on"[/color]
intellisense.
> > The
> > > SET statement actually creates the object. Now, you are ready to
invoke
> > the
> > > methods of the object. In the second example, the single line of code
> > > simply creates the variable and "turns on" intellisense. If you now
> > invoke
> > > a method of the object, VB essentially says, "Have we created that
> object
> > > yet? Because if so, I need to invoke this method. If not, let's
create
> > it
> > > 'on the fly' and invoke this method." Fine... but it's going to do
that[
color=darkred]
> > > "check to see if it exists" routine with EVERY call to a method that[/color]
you[c
olor=darkred]
> > > make. There are other "issues" with this, but this is the big one.[/color]
It
> is

> > > extremely ineffecient, since every method call now includes an extra
> step,
> > > so most VB programmers avoid it. (By the way, in VB.NET they've
" fixed

> > > this" so both of the these examples work like the first one.)
> > >
> > > I hope all of this helps.
> > >
> > > dw
> > >
> > >
> > > "Daniel Doyle" <daniel.no_spamdoyle@ukf.net> wrote in message
> > > news:#Wbclx2bCHA.1940@tkmsftngp11...
> > > > Thanks for the reply. Does this mean that you can create an instance
> > that
> > > > you do not have a reference to using CreateObject? I understand that
> you
> > > can
> > > > late bind by dimensioning an object variable as 'Object' rather than
> the
> > > > specific object you intend to use. However, my understanding is that
> > when
> > > > you do the following,
> > > >
> > > > Set objectvariable = New Object
> > > > Set objectvariable = actualobject
> > > >
> > > > you would need to have reference to the class of the actual object
> > before
> > > > you can use it's properties and methods. Does using CreateObject
mean
> > that
> > > > you do not need to explicitly reference the object's class?
> > > >
> > > > The other source of my confusion, is to whether
> > > >
> > > > Set objectvariable = actualobject (without the New)
> > > > is the same as
> > > > Set objectvariable = GetObject(path, class)
> > > >
> > > > Can GetObject do this without needing to reference the object class
at[co
lor=darkred]
> > > > design time?
> > > >
> > > > Thank you for your help. Dan.
> > > >
> > > > "Mike Hohenshilt" <hohensm@hotmail.com> wrote in message
> > > > news:#kLNpyubCHA.4208@tkmsftngp08...
> > > > > First off, for both cases, you need to use the Set keyword using
> New
> > or
> > > > > CreateObject.
> > > > >
> > > > > CreateObject is used for late binding, and New is for early[/color]
binding. [colo
r=darkred]
> > > > >
> > > > > What is this binding? If the VB compiler knows what objects you[/color]
are[c
olor=darkred]
> > > > working
> > > > > with (ie. you have made references to them), you can use early
> > binding.
> > > > > What happens is the compiler produces code that will access the
> > object's
> > > > > properties and methodes directly. Late binding is when the[/color]
compiler
> > > > doesn't
> > > > > know how to access the object directly, so I needs to use COM
> specific
> > > > > methodes that will figure it out. In the end both early and late
> > > binding
> > > > > will produce the same results. Late binding, because of the
> overhead,
> > > is
> > > > a
> > > > > bit slower.
> > > > >
> > > > > I think that about sums it up. I think those COM methods are part
> of

> > > the
> > > > > IDispatch interface, not sure though.
> > > > >
> > > > >
> > > > > "Daniel Doyle" <daniel.no_spamdoyle@ukf.net> wrote in message
> > > > > news:OEZcnrrbCHA.1940@tkmsftngp11...
> > > > > > Hello, I am looking to take the VB6 tests at some point in the
> near
> > > > future
> > > > > > (and then try to move onto .NET).
> > > > > > However, I just have this niggling question in my mind. When to
> > use...
> > > > > >
> > > > > > object = CreateObject()
> > > > > > and
> > > > > > Set object = New...
> > > > > >
> > > > > > They seem to be used interchangeably but I would like to know
the[c
olor=darkred]
> > > > > difference
> > > > > > between them (if any), and in what situation would each be used?
> > Also,
> > > > is
> > > > > > GetObject() the same as Set object = ... (without the New)?
> > > > > > I know that CreateObject and GetObject are used in VBScript -[/color]
but
> is

> > > > this
> > > > > > their only real purpose?
> > > > > > It seems like such a basic thing, but it is causing me a little
> > > > confusion.
> > > > > >
> > > > > > Thank you. Dan.
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>

Mike Hohenshilt

2002-10-09, 9:23 pm

Hmmmm...Why would a component not support instantiation with the NEW
keyword?

"Daniel Joskovski" <omnis@unet.com.mk> wrote in message
news:#d3Gfw9bCHA.1520@tkmsftngp08...
> You do great job, but sorry, I think you miss the point, let me explain
what
> I think.
> Question was When to use New and when to use CreateObject? Answer is use
NEW
> when your component support that keyword, some ActiveX Servers and older
> COM-s don't support NEW keyword (word < 7.0, Excel < 8.0) if you want to
use
> them CreateObject is only choice. Sorry for my English, I hope this help.
> Regards,
> Daniel
>
> "Daniel Doyle" <daniel.no_spamdoyle@ukf.net> wrote in message
> news:OE47Yk4bCHA.2556@tkmsftngp09...
> > Thanks for spending time on the detail of your reply - this the type of
> > answer I love to see as I feel it gives real insight into something
that,
> at
> > first glance, seems quite straightforward.
> > I understand the differences now, but will be doing more research as
there

> > does seem to be a lot more I can learn - just on this small topic
alone -
> in
> > order to gain a more complete understanding of how vb works.
> >
> > Thanks again. Dan.
> >
> > "D Weeks" <dweeks@NOSPAMmchsi.com> wrote in message
> > news:egsKbJ4bCHA.2420@tkmsftngp09...
> > > Well, hopefully this will explain it... but it will take a few
minutes. [colo
r=darkred]
> > >
> > > To really, REALLY understand what the differences are, you need to
> > > understand a bit more about something called Interfaces. VB[/color]
programmers
> > > typically use the default interface that VB creates for them
> > automatcially.
> > > It doesn't have to be that way. You can actually create the interface
> > (for
> > > example) as a Type Library File, then implement that interface in the
> DLL.
> > > Let's say for a moment you've done that. You have a Type Library File
> > (TLB)
> > > called VehicleInterface.TLB. It exposes an interface called IVehicle.
> > You
> > > have a DLL called Vehicles.DLL that includes a class called Car. Car
> > > implements the interface exposed in the TLB.
> > >
> > > There are now two ways to create an instance of a car.
> > >
> > > IF you have a reference set to the TLB AND the DLL:
> > > Dim MyCar as VehicleInterface.IVehicle
> > > Set MyCar = New Vehicles.Car
> > >
> > > If you have a reference set to the TLB ONLY.
> > > Dim MyCar as VehicleInterface.IVehicle
> > > Set MyCar = CreateObject("Vehicles.Car")
> > >
> > > Now, many VB programmers don't use TLBs or separate interfaces. They
> > simply
> > > DIM and SET to the createable class in the DLL. In that case...
> > > Dim MyCar as Vehicles.Car
> > > Set MyCar = New Vehicles.Car
> > >
> > > and
> > >
> > > Dim MyCar as Vehicles.Car
> > > Set MyCar = CreateObject("Vehicles.Car")
> > >
> > > DO the same thing, but the second example runs a little slower.
> > >
> > > And any of these would work if you changed the Dim statement to use
the[c
olor=darkred]
> > > generic Object variable (Dim MyCar as Object). But this will make[/color]
your[
color=darkred]
> > > program REMARKABLY slower AND lose your intellisense in design time.
> > > (Remember, intellisense is inabled by the DIM statement knowing[/color]
exactly
> > what
> > > you're creating.)
> > >
> > > So, the key here is this: to use the New keyword, the client MUST
have
> a
> > > reference set to the DLL. (Because, it MUST know the Globally Unique
> > > IDentifier or GUID of the class. It uses that GUID to tell the
registry
> > > what type of object to create.) If the client does NOT have a
reference
> > to
> > > the creatable object class in the DLL, it does NOT have the GUID.
> > > Therefore, it uses CreateObject and gives it the Program ID (ProgID)
of
> > the
> > > class. The client then uses the ProgID instead of the GUID to track
> down
> > > the class.
> > >
> > > GetObject is only used if instead of creating a new instance of the
> object
> > > type, you want to open an existing object. For example, if you've
saved
> a
> > > Word document, and now - through VB - you want to open that document
in[co
lor=darkred]
> > > Word. You could do NEW, but that starts a new instance of Word, then
> > you'd
> > > have to figure out how to do a file open and such. OR, you could do a
> > > GetObject on the document you want to open, and it opens that specific
> > > document in Word.
> > >
> > > Now, on to the next question...
> > >
> > > Dim MyCar as Vehicels.Car
> > > Set MyCar = New Vehicles.Car
> > >
> > > and
> > >
> > > Dim MyCar as New Vehicles.Car
> > >
> > > definitely do NOT do the same thing. In the first example, the DIM
> > > statement creates a variable called MyCar, and "turns on"[/color]
intellisense.
> > The
> > > SET statement actually creates the object. Now, you are ready to
invoke
> > the
> > > methods of the object. In the second example, the single line of code
> > > simply creates the variable and "turns on" intellisense. If you now
> > invoke
> > > a method of the object, VB essentially says, "Have we created that
> object
> > > yet? Because if so, I need to invoke this method. If not, let's
create
> > it
> > > 'on the fly' and invoke this method." Fine... but it's going to do
that[
color=darkred]
> > > "check to see if it exists" routine with EVERY call to a method that[/color]
you[c
olor=darkred]
> > > make. There are other "issues" with this, but this is the big one.[/color]
It
> is

> > > extremely ineffecient, since every method call now includes an extra
> step,
> > > so most VB programmers avoid it. (By the way, in VB.NET they've
" fixed

> > > this" so both of the these examples work like the first one.)
> > >
> > > I hope all of this helps.
> > >
> > > dw
> > >
> > >
> > > "Daniel Doyle" <daniel.no_spamdoyle@ukf.net> wrote in message
> > > news:#Wbclx2bCHA.1940@tkmsftngp11...
> > > > Thanks for the reply. Does this mean that you can create an instance
> > that
> > > > you do not have a reference to using CreateObject? I understand that
> you
> > > can
> > > > late bind by dimensioning an object variable as 'Object' rather than
> the
> > > > specific object you intend to use. However, my understanding is that
> > when
> > > > you do the following,
> > > >
> > > > Set objectvariable = New Object
> > > > Set objectvariable = actualobject
> > > >
> > > > you would need to have reference to the class of the actual object
> > before
> > > > you can use it's properties and methods. Does using CreateObject
mean
> > that
> > > > you do not need to explicitly reference the object's class?
> > > >
> > > > The other source of my confusion, is to whether
> > > >
> > > > Set objectvariable = actualobject (without the New)
> > > > is the same as
> > > > Set objectvariable = GetObject(path, class)
> > > >
> > > > Can GetObject do this without needing to reference the object class
at[co
lor=darkred]
> > > > design time?
> > > >
> > > > Thank you for your help. Dan.
> > > >
> > > > "Mike Hohenshilt" <hohensm@hotmail.com> wrote in message
> > > > news:#kLNpyubCHA.4208@tkmsftngp08...
> > > > > First off, for both cases, you need to use the Set keyword using
> New
> > or
> > > > > CreateObject.
> > > > >
> > > > > CreateObject is used for late binding, and New is for early[/color]
binding. [colo
r=darkred]
> > > > >
> > > > > What is this binding? If the VB compiler knows what objects you[/color]
are[c
olor=darkred]
> > > > working
> > > > > with (ie. you have made references to them), you can use early
> > binding.
> > > > > What happens is the compiler produces code that will access the
> > object's
> > > > > properties and methodes directly. Late binding is when the[/color]
compiler
> > > > doesn't
> > > > > know how to access the object directly, so I needs to use COM
> specific
> > > > > methodes that will figure it out. In the end both early and late
> > > binding
> > > > > will produce the same results. Late binding, because of the
> overhead,
> > > is
> > > > a
> > > > > bit slower.
> > > > >
> > > > > I think that about sums it up. I think those COM methods are part
> of

> > > the
> > > > > IDispatch interface, not sure though.
> > > > >
> > > > >
> > > > > "Daniel Doyle" <daniel.no_spamdoyle@ukf.net> wrote in message
> > > > > news:OEZcnrrbCHA.1940@tkmsftngp11...
> > > > > > Hello, I am looking to take the VB6 tests at some point in the
> near
> > > > future
> > > > > > (and then try to move onto .NET).
> > > > > > However, I just have this niggling question in my mind. When to
> > use...
> > > > > >
> > > > > > object = CreateObject()
> > > > > > and
> > > > > > Set object = New...
> > > > > >
> > > > > > They seem to be used interchangeably but I would like to know
the[c
olor=darkred]
> > > > > difference
> > > > > > between them (if any), and in what situation would each be used?
> > Also,
> > > > is
> > > > > > GetObject() the same as Set object = ... (without the New)?
> > > > > > I know that CreateObject and GetObject are used in VBScript -[/color]
but
> is

> > > > this
> > > > > > their only real purpose?
> > > > > > It seems like such a basic thing, but it is causing me a little
> > > > confusion.
> > > > > >
> > > > > > Thank you. Dan.
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>

Daniel Joskovski

2002-10-10, 8:23 pm

Sorry for misunderstanding, English is not my native language, I will try to
clear
First for Mike
New keyword use internally CLSID for instancing object, (that is why you
must set reference to component), CreateObject use ProgID for obtaining
CLSID
that mean the CLSID need not be known at compile time this allows the CLSID
to change. Thank you for this question, because it forces me to explain what
is the really difference and I think that was your intention.

Now for early versus late binding in VB
I will provide some example:

Early binding (object calls are resolved at compile time)
Dim objXL as Excel.Application
Set objXL = CreateObject("Excel.Application")
Dim objWB as Excel.Workbook
Set objWB = objXL.Workbooks.Add

Late binding (object calls are resolved at run time)
Dim objXL as Object
Set objXL = CreateObject("Excel.Application").
Dim objWB as Object
Set objWB = objXL.Workbooks.Add

I hope this will help, however I thank you both for replaying me.
Regards,
Daniel

"Mike Hohenshilt" <hohensm@hotmail.com> wrote in message
news:uns9L$$bCHA.1700@tkmsftngp08...
> Hmmmm...Why would a component not support instantiation with the NEW
> keyword?
>
> "Daniel Joskovski" <omnis@unet.com.mk> wrote in message
> news:#d3Gfw9bCHA.1520@tkmsftngp08...
> > You do great job, but sorry, I think you miss the point, let me explain
> what
> > I think.
> > Question was When to use New and when to use CreateObject? Answer is use
> NEW
> > when your component support that keyword, some ActiveX Servers and
older

> > COM-s don't support NEW keyword (word < 7.0, Excel < 8.0) if you want to
> use
> > them CreateObject is only choice. Sorry for my English, I hope this
help.
> > Regards,
> > Daniel
> >
> > "Daniel Doyle" <daniel.no_spamdoyle@ukf.net> wrote in message
> > news:OE47Yk4bCHA.2556@tkmsftngp09...
> > > Thanks for spending time on the detail of your reply - this the type
of[co
lor=darkred]
> > > answer I love to see as I feel it gives real insight into something
> that,
> > at
> > > first glance, seems quite straightforward.
> > > I understand the differences now, but will be doing more research as
> there
> > > does seem to be a lot more I can learn - just on this small topic
> alone -
> > in
> > > order to gain a more complete understanding of how vb works.
> > >
> > > Thanks again. Dan.
> > >
> > > "D Weeks" <dweeks@NOSPAMmchsi.com> wrote in message
> > > news:egsKbJ4bCHA.2420@tkmsftngp09...
> > > > Well, hopefully this will explain it... but it will take a few
> minutes.
> > > >
> > > > To really, REALLY understand what the differences are, you need to
> > > > understand a bit more about something called Interfaces. VB
> programmers[color
=darkred]
> > > > typically use the default interface that VB creates for them
> > > automatcially.
> > > > It doesn't have to be that way. You can actually create the[/color][/color]
interface
> > > (for
> > > > example) as a Type Library File, then implement that interface in
the
> > DLL.
> > > > Let's say for a moment you've done that. You have a Type Library
File[
color=darkred]
> > > (TLB)
> > > > called VehicleInterface.TLB. It exposes an interface called[/color]
IVehicle. [colo
r=darkred]
> > > You
> > > > have a DLL called Vehicles.DLL that includes a class called Car.[/color]
Car[c
olor=darkred]
> > > > implements the interface exposed in the TLB.
> > > >
> > > > There are now two ways to create an instance of a car.
> > > >
> > > > IF you have a reference set to the TLB AND the DLL:
> > > > Dim MyCar as VehicleInterface.IVehicle
> > > > Set MyCar = New Vehicles.Car
> > > >
> > > > If you have a reference set to the TLB ONLY.
> > > > Dim MyCar as VehicleInterface.IVehicle
> > > > Set MyCar = CreateObject("Vehicles.Car")
> > > >
> > > > Now, many VB programmers don't use TLBs or separate interfaces.[/color]
They[
color=darkred]
> > > simply
> > > > DIM and SET to the createable class in the DLL. In that case...
> > > > Dim MyCar as Vehicles.Car
> > > > Set MyCar = New Vehicles.Car
> > > >
> > > > and
> > > >
> > > > Dim MyCar as Vehicles.Car
> > > > Set MyCar = CreateObject("Vehicles.Car")
> > > >
> > > > DO the same thing, but the second example runs a little slower.
> > > >
> > > > And any of these would work if you changed the Dim statement to use
> the
> > > > generic Object variable (Dim MyCar as Object). But this will make
> your
> > > > program REMARKABLY slower AND lose your intellisense in design time.
> > > > (Remember, intellisense is inabled by the DIM statement knowing
> exactly
> > > what
> > > > you're creating.)
> > > >
> > > > So, the key here is this: to use the New keyword, the client MUST
> have
> > a
> > > > reference set to the DLL. (Because, it MUST know the Globally[/color]
Unique
> > > > IDentifier or GUID of the class. It uses that GUID to tell the
> registry
> > > > what type of object to create.) If the client does NOT have a
> reference
> > > to
> > > > the creatable object class in the DLL, it does NOT have the GUID.
> > > > Therefore, it uses CreateObject and gives it the Program ID (ProgID)
> of

> > > the
> > > > class. The client then uses the ProgID instead of the GUID to track
> > down
> > > > the class.
> > > >
> > > > GetObject is only used if instead of creating a new instance of the
> > object
> > > > type, you want to open an existing object. For example, if you've
> saved
> > a
> > > > Word document, and now - through VB - you want to open that document
> in

> > > > Word. You could do NEW, but that starts a new instance of Word,
then[
color=darkred]
> > > you'd
> > > > have to figure out how to do a file open and such. OR, you could do[/color]
a[col
or=darkred]
> > > > GetObject on the document you want to open, and it opens that[/color]
specific
> > > > document in Word.
> > > >
> > > > Now, on to the next question...
> > > >
> > > > Dim MyCar as Vehicels.Car
> > > > Set MyCar = New Vehicles.Car
> > > >
> > > > and
> > > >
> > > > Dim MyCar as New Vehicles.Car
> > > >
> > > > definitely do NOT do the same thing. In the first example, the DIM
> > > > statement creates a variable called MyCar, and "turns on"
> intellisense.
> > > The
> > > > SET statement actually creates the object. Now, you are ready to
> invoke
> > > the
> > > > methods of the object. In the second example, the single line of
code[
color=darkred]
> > > > simply creates the variable and "turns on" intellisense. If you now
> > > invoke
> > > > a method of the object, VB essentially says, "Have we created that
> > object
> > > > yet? Because if so, I need to invoke this method. If not, let's
> create
> > > it
> > > > 'on the fly' and invoke this method." Fine... but it's going to do
> that
> > > > "check to see if it exists" routine with EVERY call to a method that
> you
> > > > make. There are other "issues" with this, but this is the big one.
> It
> > is
> > > > extremely ineffecient, since every method call now includes an extra
> > step,
> > > > so most VB programmers avoid it. (By the way, in VB.NET they've
> " fixed
> > > > this" so both of the these examples work like the first one.)
> > > >
> > > > I hope all of this helps.
> > > >
> > > > dw
> > > >
> > > >
> > > > "Daniel Doyle" <daniel.no_spamdoyle@ukf.net> wrote in message
> > > > news:#Wbclx2bCHA.1940@tkmsftngp11...
> > > > > Thanks for the reply. Does this mean that you can create an[/color]
instance
> > > that
> > > > > you do not have a reference to using CreateObject? I understand
that
> > you
> > > > can
> > > > > late bind by dimensioning an object variable as 'Object' rather
than
> > the
> > > > > specific object you intend to use. However, my understanding is
that[
color=darkred]
> > > when
> > > > > you do the following,
> > > > >
> > > > > Set objectvariable = New Object
> > > > > Set objectvariable = actualobject
> > > > >
> > > > > you would need to have reference to the class of the actual object
> > > before
> > > > > you can use it's properties and methods. Does using CreateObject
> mean
> > > that
> > > > > you do not need to explicitly reference the object's class?
> > > > >
> > > > > The other source of my confusion, is to whether
> > > > >
> > > > > Set objectvariable = actualobject (without the New)
> > > > > is the same as
> > > > > Set objectvariable = GetObject(path, class)
> > > > >
> > > > > Can GetObject do this without needing to reference the object[/color]
class
> at

> > > > > design time?
> > > > >
> > > > > Thank you for your help. Dan.
> > > > >
> > > > > "Mike Hohenshilt" <hohensm@hotmail.com> wrote in message
> > > > > news:#kLNpyubCHA.4208@tkmsftngp08...
> > > > > > First off, for both cases, you need to use the Set keyword
using

> > New
> > > or
> > > > > > CreateObject.
> > > > > >
> > > > > > CreateObject is used for late binding, and New is for early
> binding.
> > > > > >
> > > > > > What is this binding? If the VB compiler knows what objects you
> are
> > > > > working
> > > > > > with (ie. you have made references to them), you can use early
> > > binding.
> > > > > > What happens is the compiler produces code that will access the
> > > object's
> > > > > > properties and methodes directly. Late binding is when the
> compiler
> > > > > doesn't
> > > > > > know how to access the object directly, so I needs to use COM
> > specific
> > > > > > methodes that will figure it out. In the end both early and
late[
color=darkred]
> > > > binding
> > > > > > will produce the same results. Late binding, because of the
> > overhead,
> > > > is
> > > > > a
> > > > > > bit slower.
> > > > > >
> > > > > > I think that about sums it up. I think those COM methods are[/color]
part
> > of
> > > > the
> > > > > > IDispatch interface, not sure though.
> > > > > >
> > > > > >
> > > > > > "Daniel Doyle" <daniel.no_spamdoyle@ukf.net> wrote in message
> > > > > > news:OEZcnrrbCHA.1940@tkmsftngp11...
> > > > > > > Hello, I am looking to take the VB6 tests at some point in the
> > near
> > > > > future
> > > > > > > (and then try to move onto .NET).
> > > > > > > However, I just have this niggling question in my mind. When
to[co
lor=darkred]
> > > use...
> > > > > > >
> > > > > > > object = CreateObject()
> > > > > > > and
> > > > > > > Set object = New...
> > > > > > >
> > > > > > > They seem to be used interchangeably but I would like to know
> the
> > > > > > difference
> > > > > > > between them (if any), and in what situation would each be[/color]
used? [colo
r=darkred]
> > > Also,
> > > > > is
> > > > > > > GetObject() the same as Set object = ... (without the New)?
> > > > > > > I know that CreateObject and GetObject are used in VBScript -
> but
> > is
> > > > > this
> > > > > > > their only real purpose?
> > > > > > > It seems like such a basic thing, but it is causing me a[/color]
little
> > > > > confusion.
> > > > > > >
> > > > > > > Thank you. Dan.
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>

Daniel Doyle

2002-10-11, 3:23 am

Thank you for your replies - I now feel I have a sound understanding of the
two methods.

Dan.

"Daniel Joskovski" <omnis@unet.com.mk> wrote in message
news:exEG14LcCHA.2616@tkmsftngp09...
> Sorry for misunderstanding, English is not my native language, I will try
to
> clear
> First for Mike
> New keyword use internally CLSID for instancing object, (that is why you
> must set reference to component), CreateObject use ProgID for obtaining
> CLSID
> that mean the CLSID need not be known at compile time this allows the
CLSID
> to change. Thank you for this question, because it forces me to explain
what
> is the really difference and I think that was your intention.
>
> Now for early versus late binding in VB
> I will provide some example:
>
> Early binding (object calls are resolved at compile time)
> Dim objXL as Excel.Application
> Set objXL = CreateObject("Excel.Application")
> Dim objWB as Excel.Workbook
> Set objWB = objXL.Workbooks.Add
>
> Late binding (object calls are resolved at run time)
> Dim objXL as Object
> Set objXL = CreateObject("Excel.Application").
> Dim objWB as Object
> Set objWB = objXL.Workbooks.Add
>
> I hope this will help, however I thank you both for replaying me.
> Regards,
> Daniel
>
> "Mike Hohenshilt" <hohensm@hotmail.com> wrote in message
> news:uns9L$$bCHA.1700@tkmsftngp08...
> > Hmmmm...Why would a component not support instantiation with the NEW
> > keyword?
> >
> > "Daniel Joskovski" <omnis@unet.com.mk> wrote in message
> > news:#d3Gfw9bCHA.1520@tkmsftngp08...
> > > You do great job, but sorry, I think you miss the point, let me
explain
> > what
> > > I think.
> > > Question was When to use New and when to use CreateObject? Answer is
use
> > NEW
> > > when your component support that keyword, some ActiveX Servers and
> older
> > > COM-s don't support NEW keyword (word < 7.0, Excel < 8.0) if you want
to
> > use
> > > them CreateObject is only choice. Sorry for my English, I hope this
> help.
> > > Regards,
> > > Daniel
> > >
> > > "Daniel Doyle" <daniel.no_spamdoyle@ukf.net> wrote in message
> > > news:OE47Yk4bCHA.2556@tkmsftngp09...
> > > > Thanks for spending time on the detail of your reply - this the type
> of

> > > > answer I love to see as I feel it gives real insight into something
> > that,
> > > at
> > > > first glance, seems quite straightforward.
> > > > I understand the differences now, but will be doing more research as
> > there
> > > > does seem to be a lot more I can learn - just on this small topic
> > alone -
> > > in
> > > > order to gain a more complete understanding of how vb works.
> > > >
> > > > Thanks again. Dan.
> > > >
> > > > "D Weeks" <dweeks@NOSPAMmchsi.com> wrote in message
> > > > news:egsKbJ4bCHA.2420@tkmsftngp09...
> > > > > Well, hopefully this will explain it... but it will take a few
> > minutes.
> > > > >
> > > > > To really, REALLY understand what the differences are, you need to
> > > > > understand a bit more about something called Interfaces. VB
> > programmers
> > > > > typically use the default interface that VB creates for them
> > > > automatcially.
> > > > > It doesn't have to be that way. You can actually create the
> interface
> > > > (for
> > > > > example) as a Type Library File, then implement that interface in
> the
> > > DLL.
> > > > > Let's say for a moment you've done that. You have a Type Library
> File
> > > > (TLB)
> > > > > called VehicleInterface.TLB. It exposes an interface called
> IVehicle.
> > > > You
> > > > > have a DLL called Vehicles.DLL that includes a class called Car.
> Car
> > > > > implements the interface exposed in the TLB.
> > > > >
> > > > > There are now two ways to create an instance of a car.
> > > > >
> > > > > IF you have a reference set to the TLB AND the DLL:
> > > > > Dim MyCar as VehicleInterface.IVehicle
> > > > > Set MyCar = New Vehicles.Car
> > > > >
> > > > > If you have a reference set to the TLB ONLY.
> > > > > Dim MyCar as VehicleInterface.IVehicle
> > > > > Set MyCar = CreateObject("Vehicles.Car")
> > > > >
> > > > > Now, many VB programmers don't use TLBs or separate interfaces.
> They
> > > > simply
> > > > > DIM and SET to the createable class in the DLL. In that case...
> > > > > Dim MyCar as Vehicles.Car
> > > > > Set MyCar = New Vehicles.Car
> > > > >
> > > > > and
> > > > >
> > > > > Dim MyCar as Vehicles.Car
> > > > > Set MyCar = CreateObject("Vehicles.Car")
> > > > >
> > > > > DO the same thing, but the second example runs a little slower.
> > > > >
> > > > > And any of these would work if you changed the Dim statement to
use
> > the
> > > > > generic Object variable (Dim MyCar as Object). But this will make
> > your
> > > > > program REMARKABLY slower AND lose your intellisense in design
time. [colo
r=darkred]
> > > > > (Remember, intellisense is inabled by the DIM statement knowing
> > exactly
> > > > what
> > > > > you're creating.)
> > > > >
> > > > > So, the key here is this: to use the New keyword, the client MUST
> > have
> > > a
> > > > > reference set to the DLL. (Because, it MUST know the Globally
> Unique
> > > > > IDentifier or GUID of the class. It uses that GUID to tell the
> > registry
> > > > > what type of object to create.) If the client does NOT have a
> > reference
> > > > to
> > > > > the creatable object class in the DLL, it does NOT have the GUID.
> > > > > Therefore, it uses CreateObject and gives it the Program ID[/color]
(ProgID)
> > of
> > > > the
> > > > > class. The client then uses the ProgID instead of the GUID to
track

> > > down
> > > > > the class.
> > > > >
> > > > > GetObject is only used if instead of creating a new instance of
the[c
olor=darkred]
> > > object
> > > > > type, you want to open an existing object. For example, if you've
> > saved
> > > a
> > > > > Word document, and now - through VB - you want to open that[/color]
document
> > in
> > > > > Word. You could do NEW, but that starts a new instance of Word,
> then
> > > > you'd
> > > > > have to figure out how to do a file open and such. OR, you could
do
> a
> > > > > GetObject on the document you want to open, and it opens that
> specific
> > > > > document in Word.
> > > > >
> > > > > Now, on to the next question...
> > > > >
> > > > > Dim MyCar as Vehicels.Car
> > > > > Set MyCar = New Vehicles.Car
> > > > >
> > > > > and
> > > > >
> > > > > Dim MyCar as New Vehicles.Car
> > > > >
> > > > > definitely do NOT do the same thing. In the first example, the
DIM[c
olor=darkred]
> > > > > statement creates a variable called MyCar, and "turns on"
> > intellisense.
> > > > The
> > > > > SET statement actually creates the object. Now, you are ready to
> > invoke
> > > > the
> > > > > methods of the object. In the second example, the single line of
> code
> > > > > simply creates the variable and "turns on" intellisense. If you[/color]
now[c
olor=darkred]
> > > > invoke
> > > > > a method of the object, VB essentially says, "Have we created that
> > > object
> > > > > yet? Because if so, I need to invoke this method. If not, let's
> > create
> > > > it
> > > > > 'on the fly' and invoke this method." Fine... but it's going to[/color]
do
> > that
> > > > > "check to see if it exists" routine with EVERY call to a method
that
> > you
> > > > > make. There are other "issues" with this, but this is the big
one.
> > It
> > > is
> > > > > extremely ineffecient, since every method call now includes an
extra

> > > step,
> > > > > so most VB programmers avoid it. (By the way, in VB.NET they've
> > "fixed
> > > > > this" so both of the these examples work like the first one.)
> > > > >
> > > > > I hope all of this helps.
> > > > >
> > > > > dw
> > > > >
> > > > >
> > > > > "Daniel Doyle" <daniel.no_spamdoyle@ukf.net> wrote in message
> > > > > news:#Wbclx2bCHA.1940@tkmsftngp11...
> > > > > > Thanks for the reply. Does this mean that you can create an
> instance
> > > > that
> > > > > > you do not have a reference to using CreateObject? I understand
> that
> > > you
> > > > > can
> > > > > > late bind by dimensioning an object variable as 'Object' rather
> than
> > > the
> > > > > > specific object you intend to use. However, my understanding is
> that
> > > > when
> > > > > > you do the following,
> > > > > >
> > > > > > Set objectvariable = New Object
> > > > > > Set objectvariable = actualobject
> > > > > >
> > > > > > you would need to have reference to the class of the actual
object
> > > > before
> > > > > > you can use it's properties and methods. Does using CreateObject
> > mean
> > > > that
> > > > > > you do not need to explicitly reference the object's class?
> > > > > >
> > > > > > The other source of my confusion, is to whether
> > > > > >
> > > > > > Set objectvariable = actualobject (without the New)
> > > > > > is the same as
> > > > > > Set objectvariable = GetObject(path, class)
> > > > > >
> > > > > > Can GetObject do this without needing to reference the object
> class
> > at
> > > > > > design time?
> > > > > >
> > > > > > Thank you for your help. Dan.
> > > > > >
> > > > > > "Mike Hohenshilt" <hohensm@hotmail.com> wrote in message
> > > > > > news:#kLNpyubCHA.4208@tkmsftngp08...
> > > > > > > First off, for both cases, you need to use the Set keyword
> using
> > > New
> > > > or
> > > > > > > CreateObject.
> > > > > > >
> > > > > > > CreateObject is used for late binding, and New is for early
> > binding.
> > > > > > >
> > > > > > > What is this binding? If the VB compiler knows what objects
you
> > are
> > > > > > working
> > > > > > > with (ie. you have made references to them), you can use early
> > > > binding.
> > > > > > > What happens is the compiler produces code that will access
the[c
olor=darkred]
> > > > object's
> > > > > > > properties and methodes directly. Late binding is when the
> > compiler
> > > > > > doesn't
> > > > > > > know how to access the object directly, so I needs to use COM
> > > specific
> > > > > > > methodes that will figure it out. In the end both early and
> late
> > > > > binding
> > > > > > > will produce the same results. Late binding, because of the
> > > overhead,
> > > > > is
> > > > > > a
> > > > > > > bit slower.
> > > > > > >
> > > > > > > I think that about sums it up. I think those COM methods are
> part
> > > of
> > > > > the
> > > > > > > IDispatch interface, not sure though.
> > > > > > >
> > > > > > >
> > > > > > > "Daniel Doyle" <daniel.no_spamdoyle@ukf.net> wrote in message
> > > > > > > news:OEZcnrrbCHA.1940@tkmsftngp11...
> > > > > > > > Hello, I am looking to take the VB6 tests at some point in[/color]
the[c
olor=darkred]
> > > near
> > > > > > future
> > > > > > > > (and then try to move onto .NET).
> > > > > > > > However, I just have this niggling question in my mind. When
> to

> > > > use...
> > > > > > > >
> > > > > > > > object = CreateObject()
> > > > > > > > and
> > > > > > > > Set object = New...
> > > > > > > >
> > > > > > > > They seem to be used interchangeably but I would like to[/color]
know
> > the
> > > > > > > difference
> > > > > > > > between them (if any), and in what situation would each be
> used?
> > > > Also,
> > > > > > is
> > > > > > > > GetObject() the same as Set object = ... (without the New)?
> > > > > > > > I know that CreateObject and GetObject are used in
VBScript -
> > but
> > > is
> > > > > > this
> > > > > > > > their only real purpose?
> > > > > > > > It seems like such a basic thing, but it is causing me a
> little