Home > Archive > Visual Basic > February 2005 > VB6 / WIN XP : Object methods failures - HELP !
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
VB6 / WIN XP : Object methods failures - HELP !
|
|
| Brian Elliott 2005-02-26, 8:55 pm |
| I have working VB6 [ Student Ed. ] programs running under WIN 98 SE.
When transferred to WIN XP systems they fail at statements such as :-
Set wbook1 = excel1.Workbooks.Open ("c:\... etc. ") or alternatives such as
:-
Set appExcel = GetObject ( "c:\.... etc. ")
with the error ' Method ' Open ' of Object workbooks failed'. I have set
References and Components to include Microsoft Object Library 8.0 and have
defined excel1 with Public excel1 as New Excel.Application correctly etc.
etc.
I am using an old version of Office ie Office 97 - could the problem lie
here ?
I have downloaded service packs for VB6 but to no avail. Any suggestions
please - I bought this machine specifically as a back up system for these
VB6 programs !
| |
|
| Does the new machine include Office? If so, is it the same version as your
development machine? If not, then you will need to use late binding to the
Excel Object library...
--
Chris Hanscom - Microsoft MVP (VB)
Veign's Resource Center
http://www.veign.com/vrc_main.asp
--
"Brian Elliott" <bre2@tesco.net> wrote in message
news:d94Ud.840$Uz.556@newsfe3-gui.ntli.net...
> I have working VB6 [ Student Ed. ] programs running under WIN 98 SE.
>
> When transferred to WIN XP systems they fail at statements such as :-
>
> Set wbook1 = excel1.Workbooks.Open ("c:\... etc. ") or alternatives such
as
> :-
>
> Set appExcel = GetObject ( "c:\.... etc. ")
>
> with the error ' Method ' Open ' of Object workbooks failed'. I have
set
> References and Components to include Microsoft Object Library 8.0 and have
> defined excel1 with Public excel1 as New Excel.Application correctly etc.
> etc.
>
> I am using an old version of Office ie Office 97 - could the problem lie
> here ?
>
> I have downloaded service packs for VB6 but to no avail. Any suggestions
> please - I bought this machine specifically as a back up system for these
> VB6 programs !
>
>
>
>
| |
| Brian Elliott 2005-02-27, 3:55 pm |
| Thankyou - could you please explain what ' Late Binding ' is and better
still on how to implement it - thanks.
"Veign" <NOSPAMinveign@veign.com> wrote in message
news:eCvy%230DHFHA.3076@tk2msftngp13.phx.gbl...
> Does the new machine include Office? If so, is it the same version as
> your
> development machine? If not, then you will need to use late binding to
> the
> Excel Object library...
>
> --
> Chris Hanscom - Microsoft MVP (VB)
> Veign's Resource Center
> http://www.veign.com/vrc_main.asp
> --
>
> "Brian Elliott" <bre2@tesco.net> wrote in message
> news:d94Ud.840$Uz.556@newsfe3-gui.ntli.net...
> as
> set
>
>
| |
| Larry Serflaten 2005-02-27, 8:55 pm |
|
"Brian Elliott" <bre2@tesco.net> wrote
> Thankyou - could you please explain what ' Late Binding ' is and better
> still on how to implement it - thanks.
Late binding involves using external objects that the VB compiler knows
nothing about. Early binding (conversely) means the compiler is aware
of those type of objects.
To achieve Early binding you add references and declare your object
variables as specific types. To achieve Late binding, you do not add
references and declare your object variables as type Object (or Variant).
Intellisense only works on Early bound objects. If you see Intellisense
working, then you can know that object is early bound. (There are a few
cases where Intellisense fails to work on early bound objects, but as a
general rule, you can use it as a guide, as well as looking at your variable
declararions.)
The Early or Lateness is decided by the declaration line of your variables.
LFS
| |
|
| Adding to Larry's post.
The reason to use Late Binding in this situation is because at design time
you will not have knowledge of the proper Excel library to use. Meaning
some of the machines may use the 8.0 library and others may use the 11.0
library. As long as you use late binding (like Larry S described) and use
properties and methods that are common to both libraries your application
can run on either machine. This gives you flexibility to write applications
that interface with different Office versions without providing / compiling
different versions of your application.
--
Chris Hanscom - Microsoft MVP (VB)
Veign's Resource Center
http://www.veign.com/vrc_main.asp
--
"Brian Elliott" <bre2@tesco.net> wrote in message
news:rVnUd.3922$dy3.2002@newsfe1-gui.ntli.net...
> Thankyou - could you please explain what ' Late Binding ' is and better
> still on how to implement it - thanks.
> "Veign" <NOSPAMinveign@veign.com> wrote in message
> news:eCvy%230DHFHA.3076@tk2msftngp13.phx.gbl...
such[color=darkred]
have[color=darkred]
etc.[color=darkred]
lie[color=darkred]
suggestions[color=darkred]
these[color=darkred]
>
>
| |
|
|
"Brian Elliott" <bre2@tesco.net> wrote in message
news:rVnUd.3922$dy3.2002@newsfe1-gui.ntli.net...
> Thankyou - could you please explain what ' Late Binding ' is and better
> still on how to implement it - thanks.
To add to Larry's response, late-bound references to objects also impose a
performance hit. This is because the object type needs to be looked up in
the Registry as opposed to it already being compiled in your app. The
severity of the performance hit depends on how frequently the object
variable is used. Every use of a property or method of a late-bound object
involves additional calls to COM that aren't necessary if the reference is
early-bound. Individually, these performance hits are very slight (so much
so that even several would be unnoticeable). Collectively, they could add
up to make a noticeable difference. These calls to COM occur
on-the-fly...IOW, only when the code is actually executed. For this reason,
you won't get compile-time errors if you try to use a property or method
that the object doesn't have. Instead, you get a runtime error (which can
be trapped).
Also, to reitterate a point that Larry touched on (but one that I think
deserves more explanation), what determines whether an object reference is
late-bound or early-bound depends *soley* on the declaration of the object
variable. Many people either get  by this or are just out and out
wrong about it. They incorrectly think that it depends on how the object
gets instantiated (created) or it depends on a combination of the
declaration and how it gets instantiated. How the object gets instantiated
has NOTHING to do with whether it's early-bound or late-bound.
Here are some examples:
This is a late-bound reference to MS Word's Application object. No
reference to the Word object library (in VB's References dialog box) is
necessary. This is how you must declare late-bound references* and how you
generally instantiate the object when the reference is late-bound.
Dim MyObject As Object
Set MyObject = CreateObject("Word.Application")
* - As Larry noted, you could declare the object variable As Variant, but
this is extremely rare and in fact, would affect performance negatively even
more (and require more memory).
This is also a late-bound reference because the variable is declared As
Object. A reference to the Word object library, however, is required due to
the way the object is being instantiated. You'll very rarely see something
like this. If you do, it's usually just to make a point (as is the case
here) or it's a mistake. But it is valid and does work. There's just no
good reason (that I can think of) for actually doing it like this.
Dim MyObject As Object
Set MyObject = New Word.Application
This is an early-bound reference. A reference to the Word object library is
required. This is generally how you should declare and instantiate
early-bound references.
Dim MyObject As Word.Application
Set MyObject = New Word.Application
This is the one that causes the most confusion. This is an early-bound
reference. A reference to the Word object library is required. For some
reason, people think that if you use CreateObject, it's late-bound, and
that's not the case.
Dim MyObject As Word.Application
Set MyObject = CreateObject("Word.Application")
However, the above DOES involves additional COM calls when instantiating the
object because the string "Word.Application" used in CreateObject needs to
be looked up in the Registry (something not necessary if you use code as in
the 3rd example). After that, though, no additional COM calls are needed
because the object's properties and methods are already known.
Now, just for completeness, here's another way for an early-bound reference,
but it's one you should NEVER use:
Dim MyObject As New Word.Application
You can run into numerous problems with code like that. For one, you're
telling VB to wrap EVERY use of the object variable as such (IOW, VB
automatically adds this "code" during compilation):
If MyObject Is Nothing Then
Set MyObject = New ObjectType
End If
This affects performance. Besides that, you can never check if the object
variable is Nothing because any use of it automatically instantiates it.
Consider the following code in a form (first, open VB's References window
and add a reference to the Microsoft Word Object Library):
Dim MyObject As New Word.Application
MyObject.Visible = True
MyObject.Quit
Set MyObject = Nothing
If MyObject Is Nothing Then
Unload Me
End If
The form will not get unloaded because by checking the expression "MyObject
Is Nothing", MyObject gets instantiated; so the evaluation is always False.
Even worse, Word is running invisibly! Try the above code. Open Task
Manager (set the Always On Top option) and go to the Processes tab. Step
through the code and watch for the WINWORD.EXE process in Task Manager.
You'll have to right-click on WINWORD.EXE in Task Manager and choose End
Process to get rid of it. Oh, and make sure Word is not already running
when you do this; otherwise, you may end the wrong instance of Word (and
lose data since you won't get prompted to save anything that's changed).
And that's just barely touching the surface of the problems you can run into
using "Dim objvar As New objtype". You'll see that syntax a lot, especially
in VB examples in MSDN Library/VB's Help, the KB, etc. Don't get bitten by
it. Just because some MS employees who wrote examples for VB use such code
doesn't mean it is "good" code. In fact, most of MS's example VB code is,
well, let's just say that it's not always of the highest quality.
Hmm. There was something else I was going to comment on too, but then I got
on this Dim As New tanget and forgot what it was. <g> It'll come to me.
--
Mike
Microsoft MVP Visual Basic
|
|
|
|
|