Word Object Library Serious compatability problem with VB -Useful Info

Micorsoft knows this problem exists but has done nothing to fix the Word library itself. It took a week to find the answer to this problem....


The VB interface crashes when a reference is set to the word object library as soon as you DIM something...



here is the Answer.................

Fix the Word Object library

BUG: Automation Client Receives Error or Crashes Calling Word's Find Object
This article applies to…
This article was previously published under Q292744
SYMPTOMS
When you use an out-of-process client application that uses early binding to Automate Word 97 or later, the application may crash with an access violation or you may receive one of the following error messages:

From Microsoft Visual Basic:

The Interface will simply carash as soon as you insert a space after the Variable Name.. (The article at the link doesn't mention this this is why i had so much trouble finding the solution.

Run-time error '-2147023113 (800706f7)':
The method '~' of object '~' failed


Run-time error '-2147023113 (800706f7)':
Method 'Execute' of object 'Find' failed


Run-time error 430:
Class does not support automation or does not support expected interface.
From Microsoft Visual C++:

HRESULT = 0x800706F7
RPC_X_BAD_STUB_DATA - The stub received bad data.
NOTE: In debug builds you receive a corrupt stack warning from an Assert dialog box, and the value of EAX is that listed above. In release builds, the stack corruption will likely crash the application soon after this point, but the HRESULT value is likely to be similar to the above.

The problem occurs consistently on some computers, but may never occur on others. Installing a new application or a Microsoft Excel service pack can cause a computer that was working previously to experience the problem.


The information in this article applies to:
Microsoft Office Word 2003
Microsoft Word 2002
Microsoft Word 2000
Microsoft Word 97 for Windows
Microsoft Visual Basic Professional Edition for Windows 6.0
Microsoft Visual Basic Enterprise Edition for Windows 6.0
Microsoft Visual C++, 32-bit Professional Edition 6.0



Etc....

it's not very valuable :mad: you lied to me through subject!!! I hate it when people do that!!!:rolleyes:

If you went to the link provided you would see it is a microsoft document and nothing to do with me..

I had the porblem and could not reolve it for a week, which as you might guess could be very bad for progress...

Thus if you had the problem this info would be very important to you..


with respect

Steve

Quote:

---

Originally posted by BuggyProgrammer
it's not very valuable :mad: you lied to me through subject!!! I hate it when people do that!!!:rolleyes:

---

:rolleyes: i hate when people steal from the simpsons :rolleyes:

ZING :p

So the interface crashes how can there be error numbers or messages for that matter?

Lied??? It may not be important to you ... but it may be to others..

:D Blah... I can't spell either it seems!!!

ahahha...





:p :bigyello:

Why would you use early binding in a release application though ?

But frankly having had the horrors from version conflicts myself, i would also suggest late binding in a release version.. I convert my bindings at release time because it saves developement time to use early binding for the reasons detailed in Daves article below.. I also dont have a photographic memory to remember every available method or property that is available in a givevn library etc..

Early vs. Late Binding

Quoted from an article on MVP

http://www.mvps.org/word/FAQs/InterD...ateBinding.htm

Article contributed by Dave Rado


There are two ways to use Automation (or OLE Automation) to programmatically control another application.

Late binding uses CreateObject to create and instance of the application object, which you can then control. For example, to create a new instance of Excel using late binding:

Dim oXL As Object
Set oXL = CreateObject("Excel.Application")

On the other hand, to manipulate an existing instance of Excel (if Excel is already open) you would use GetObject (regardless whether you're using early or late binding):

Dim oXL As Object
Set oXL = GetObject(, "Excel.Application")

To use early binding, you first need to set a reference in your project to the application you want to manipulate. In the VB Editor of any Office application, or in VB itself, you do this by selecting Tools + References, and selecting the application you want from the list (e.g. “Microsoft Excel 8.0 Object Library”).

To create a new instance of Excel using early binding:

Dim oXL As Excel.Application
Set oXL = New Excel.Application

In either case, incidentally, you can first try to get an existing instance of Excel, and if that returns an error, you can create a new instance in your error handler.


Advantages of Early Binding
1.
Your code will run considerably faster, because it can all be compiled up front. With late binding, the code relating to an application you declared as an object has to, in effect, be compiled as it runs.


2.
Because your code can all be compiled up front, debugging is far easier – select Debug + Compile, and the compiler will be able to spot syntax errors which would have been missed had you used late binding.


3.
You have full access in your project to intellisense (type a keyword and a dot to get a popup list of properties and methods supported by that keyword, select one to insert it; type a keyword and press F1 to launch the Help topic on that keyword).


4.
You have full access to the application's object model via the Object Browser and VBA Help.


5.
You have access to the application's built-in constants. For instance, if you are automating Word from Excel, you can use:

Dim objWord As Word.Application
Set objWord = New Word.Application

With objWord
.Visible = True
.Activate
.WindowState = wdWindowStateMaximize
.Documents.Open ("c:\temp\temp.doc")
End With

Furthermore, when you type

.WindowState =

you'll get a pop-up list of the supported constants, and can simply pick “wdWindowStateMaximize” from the list.

If you used late binding, you would need to use:

.WindowState = 1

.. and you would need to know (by looking it up in Word's Object Browser) that the value of the constant “wdWindowStateMaximize” happens to be 1.


All this makes programming using early binding immeasurably easier than using late binding.


Advantages of Late Binding
1.
The main advantage is that code which uses late binding is more certain to be version-independent

If you set a reference in a Word 97 project to “Microsoft Excel 8.0 Object Library”, then the project willrun OK on a machine which has Office 2000 installed. Word 2000 changes the reference on the fly to the “Microsoft Excel 9.0 Object Library”.

But as they famously say, YMMV. Problems have been found in certain circumstances. For instance, if you run a Word 97 project containing a reference to the Excel 8.0 object library on a machine with Office 2000 installed, it will run OK, but you may get the occasional “cannot open macro storage” error unless you save the project in Word 2000. If you do save it in Word 2000, the reference will change to the Excel 9.0 object library. So if you use early binding and support a mixed environment, it may be safest to create separate Word 97 and Word 2000 versions of your addins, despite the maintenance overhead.


2.
The more references your project contains, the larger the file size and the longer it takes to compile.


3.
Some programming environments don't allow you to create references to another application.



Summary
Personally, as someone who finds programming difficult at the best of times, I would never dream of using late binding – why make life harder for yourself than it has to be? But some programming geniuses prefer to use late binding, because of the peace of mind it gives them regarding version independence – or maybe some of them just enjoy the challenge! <g> But you pays your money and makes your choice ...

To those unfortunate souls using programming environments in which you have to use late binding, all I can say is: Look on the bright side – you could have ended up as an Assembly language programmer ...

Hmmmm...maybe instead of:

This is Very Valueable Info for VB Programmers

You may want to change it to:

Word 97+ documented serious compatibility problems with VB6. Useful Information

Just a thought.

Woka