Board index » Visual Studio » Word 97 and Word 2003

Visual Studio22
Hi all,



I have an application that used Word 97 to output a document based on info

stored in a VB6 program. It has been working perfectly until our company

decided to upgrade to Word 2003.



Now my users are getting errors as Word97 has been removed from their

systems and Word 2003 added. Unfortunately, (or fortunately), I still have

Word97 installed (as well as Word 2003) so I don't get the errors.



My guess is that it's something to do with early (which I do) and late

binding, and the MSWORD8.OLB(97) and MSWORD.OLB (2003) files. But what? And

maybe more to the point, why? (or should that be a given as it's a M$

product <g>)



TIA

Martin


-

"Martin Walke" <martin.walke_no_spam@vega_dot_co_dot_uk>wrote in message

The .olb files are essentially type libraries used for earlier binding to

specific Office Object Libraries (Automation). They are only used only

during development to resolve references to specific Office libraries. They

are not distribute-able nor do they have any use to a running application.



You say you are using Early and Late binding, but if your project contains

ANY reference to an office library, your are using early binding.



Your choices are 1) convert the current application to use Late binding

through-out and make no reference to a specific library/product, or 2)

convert your application (supply an new version) that accesses the Version

11 library.



Since this is an enterprise migration I would probably chose the latter.



hth

-ralph





-

Recompile the apps on your system using Word 97 with early binding.

Subject to errors in your code, or incompatibilities with the more recent

Word, the compiled app should work on a Word 2003 system.



For example, www.standards.com/index.html?Sorting">www.standards.com/index.html?Sorting was compiled using

both Excel 97 and Word 97, but works with later versions of Office as well.



Always use early binding, except in those circumstances where it cannot be

used.

In other words, keep your Office 97 around so you can compile with Office

97.



In some cases, later versions of Office implement things differently, and

you will need to change the logic of your program to accommodate such

changes.



If you know that all will be using Word 2003, repeat the above, but use Word

2003 to compile with VB 6.



--

www.standards.com/;">www.standards.com/; See Howard Kaikow's web site.





-

"Ralph" <nt_consulting64@yahoo.com>wrote in message



Not necessarily. Binding is determined by the declaration of the object

variable. So, even though you may have a reference to the Word object

library, if you declare the object variable 'Dim oWordApp As Object', you're

using late-binding.





Personally, I've never encountered a problem when early-binding to an

earlier version of Office and that app running on a PC with a later version

of Office. Maybe I've just been lucky.



--

Mike

Microsoft MVP Visual Basic



-

Hi,

I would recommend you to use CreateObject("") i.e LateBinding so that you

will not face any problem with different versions of Word



Best Regards,

Paresh Naik



"Howard Kaikow" wrote:

Inline



"MikeD" <nobody@nowhere.edu>wrote in message

Quite correct, but I didn't really want to go that far into it and should

have said "you are *probably* using early binding.



I was thinking where a programmer might call CreateObject() to set a

reference to a fully qualified reference variable, or upon creating an

Object reference to an OfficeApp procede to set some element from a

collection to a fully qualified reference - all the while thinking he was

still using late-binding.



In practical use if you set a Project Reference to an Office object it is

difficult to not go ahead and use it. Not a big issue, but results can

occasionally be surprising as the app can end up more tightly linked than

the programmer intended.



Again I just suggested (imho based on my humble experience) the simpler

route. The OP has a working app that just stuttered with the company

upgrade. Seems like he/she should have gotten away with it - but something

broke - he was unlucky. Lot's of possible reasons, by simply replacing the

project reference most problems will become very clear and it is a very

simple fix. Why go into Word97 vs Word2003 issues, if the target/goal is to

work with Word2003?



Besides once your customers move on it becomes the classic Fram Filter

dilemma - "Pay me now or pay me later". Now is usually cheaper than later.

<g>



-ralph





-

"Martin Walke" <martin.walke_no_spam@vega_dot_co_dot_uk>'s

wild thoughts were released on Wed, 5 Jul 2006 16:28:04

+0100 bearing the following fruit:



What's the error? We can't really tell you anything until we

know that.



As a side note, your quite correct to compile against the

earliest version you intend to support.











Jan Hyde (VB MVP)



--

The first scientists who studied fog were mistified. (Mike Bull)



-

Thanks all, for replying.



I do use only early binding, initially so that I could have intellisense

working in my favour, as this was my first venture into Word automation. I

only mentioned late binding for completeness but have a feeling that that's

the path to take.



The different declaration I have are:



Dim objWord As Word.Application

Dim WordDoc As Word.Document



Now these are easier enough to convert to late binding by simply replacing

with 'as Object'. But what do I do with the 'WithEvents' definitions?



Public WithEvents objWord As Word.Application

Public WithEvents WordDoc As Word.Document



Do I replace the Word.Application with Object, etc?



I can't just recompile with the Word 2003 reference as (and i didn't make

this clear), it must still work for off-site users (at home) who still have

Word97.



A couple of responses mentioned that there *should* be effective backwards

compatibility when compiling with Word97 and running in a Word 2003

environment. I couldn't agree more but somewhere something's not playing the

game. I have also experienced something similar with VBA under Excel97,

running in a Excel 2003 environment.



Of course, this issue may well be a total red herring and it has nothing to

do with early/late binding but that seems to be the likely culprit at the

moment.



Martin





"Ralph" <nt_consulting64@yahoo.com>wrote in message



-

Jan,



The error is "3061 - Too few parameters. Expected 1" on a line:



objWord.Selection.InsertAfter .TextMatrix(CurPos, 1)



Martin



"Jan Hyde" <StellaDrinker@REMOVE.ME.uboot.com>wrote in message



-

"Martin Walke" <martin.walke_no_spam@vega_dot_co_dot_uk>wrote in message



You can't use "WithEvents" with LateBinding.



Is your app constructed in such that the actual Word Automation routines

could be isolated into their own component/s without a complete re-write?



-ralph









-

May sound stupid, but have you checked the value of .TextMatrix(CurPos, 1)

when the statement fails?



InsertAfter expects a string of characters. If you pass it something else,

it'll get very confused... even if it's null.



Also, I would guess that this is in the middle of a "With" block... I had

all sorts of problems using automation in the middle of With blocks. So much

so that I never use With in association with automation.



I think you should also think very hard about whether you need the

WithEvents stuff in you app. If you can eliminate it and got to late

binding, your apps will become more stable. I had major problems automating

Excel (and several embarrassing client site visits) when I was using early

binding which went away when I switched to late binding.



Regards getting intellisence.. just define the objects twice; once as Object

and once as the real object (Range, Document etc). Just comment out the one

you don't need at the time. So, when you need intellisence (during

development and initial testing) use the real object. Final testing and

distribution is done with the real object commented out and the "object"

definition in place. Not elegant, but works.



HTH

Steve





"Martin Walke" <martin.walke_no_spam@vega_dot_co_dot_uk>wrote in message



-

"Martin Walke" <martin.walke_no_spam@vega_dot_co_dot_uk>'s

wild thoughts were released on Thu, 6 Jul 2006 12:24:13

+0100 bearing the following fruit:



A quick google on that error message seem to point toward

database access of some kind - is that the case in your app?



J





Jan Hyde (VB MVP)



--

As far as we know, our computer has never had an undetected error.



-

Thanks for your input



Martin



"Ralph" <nt_consulting64@yahoo.com>wrote in message



-

Got it!! Thanks Steve. Although not what i expected.



I replaced the .textmatrix with a fully qualified reference and it all

*seems* to work correctly. I do remember back when i started with Word

automation that it didn't like using the 'with' statement but it obviously

was getting confused about what went where......



Many thanks to all that responded



Martin





"Steve Barnett" <noname@nodomain.com>wrote in message



-

Thanks Jan. I also checked, as 3000 errors are normally associated with DBs.

My grid isn't bound although it was filled from a DB. I have sorted it now

as per my reply to Steve's suggestion. Thanks for replying.



Martin





"Jan Hyde" <StellaDrinker@REMOVE.ME.uboot.com>wrote in message



-

You're welcome.



You'll also ever see a With statement in any of my code.



Steve



"Martin Walke" <martin.walke_no_spam@vega_dot_co_dot_uk>wrote in message



-

"Steve Barnett" <noname@nodomain.com>wrote in message

I'm interested to get to the bottom of why best not to use 'With', as often

recommended particularly while automating Office app's in VB. For my

purposes I find reducing the number of dots noticeably improves performance

in some scenarios and so I prefer to use With.



However I'm careful to ensure I always get to the 'End With', eg



On Error goto errH



With.myObj.SubObj1.Prop1

' do stuff

' some error perhaps

exitWith:

End With



If myError = 1 then.... else...end If



errH:

myError = 1

Resume exitWith



I hope this approach is OK and not aware of problems I can attribute to use

of With. But I'd be interested (but not pleased!) to know if I'm potentially

missing something.



Regards,

Peter T





-

"Peter T" <peter_t@discussions>wrote in message

[Here we go again. <g>]



There are no 'problems' with using the With...End With construct. It is

convenient, works well, and definitely adds clarity to code.



But it is an artifact of languages that have interpreted roots. Back when

the interpreter had to "re-dereference" a statement like

"myObj.SubObj1.Prop1" each time it came across, it there was an advantage to

creating a single temporary reference and use it as a replacement within a

block of code. This construction offered a real performance boost.



There is less need for using this construct in compiled languages (or highly

optimized pcode generators), in fact creating your own temporary reference,

or not using the block, may even be faster. (eg, your example might turn

into this...)

Set tmp = myObj.SubObj1.Prop1

tmp.do_stuff

tmp.do_more

tmp.Stuff = "A"

...

The above construct saves the requirement of creating the block, destroying

the temporary reference (let the normal exit from a procedure handle it),

and allows a GoTo to be inserted anywhere.



The difference is very minute. And IMHO isn't great enough to override the

many other advantages of using With...End With. But there are those that

don't share that opinion. [Do a little googling in this newsgroup for past

discussions.] To them simplicity and clarity always take a back seat when it

comes to removing that last click of possible 'delay'.



It is an ancient debate. <g>



-ralph







-

I only have two objections to using With...



Most of the times I used it for anything non-trivial, I ended up removing it

due to the bugs it introduced. Of course, this might be because my

non-trivial code is usually related to automation of one of the MS-Office

packages, so it might just be that it's not compatible with automation,

where there is a lot of cross application interaction, which must make

memory management and the marshalling of data a nightmare for the compiler

writers.



The second is basically coding style. I just prefer to ensure that

everything that can self document does so. By using With, you disconnect a

property or method from the object to which it relates. The only purpose I

can see in doing this is to reduce your typing and that's not a good enough

reason in my book. I have copy and paste available to me, so explicitly

naming the object isn't a big issue and it makes the code more obvious.



No doubts there is a performance hit in specifying the object every time, as

I would expect that using With means that the object reference only gets

resolved once but, in my opinion, the performance hit isn't big enough to

matter in the majority of applications.



I guess, in summary, there are too many potential downsides to using With in

my circumstance. If you're happy with it, then use it, but be prepared to

strip it out when you get strange bugs (especially with calls to automation

of external DLL's).



Oh yes, and I now have the mind-set that just never considers With, so it's

easy to ignore, like Goto and End.



Steve





"Peter T" <peter_t@discussions>wrote in message



-

"Steve Barnett" <noname@nodomain.com>wrote in message

Would be very interested in knowing more about these "bugs" that are

introduced when using a With...End With statement.



Another interesting observation. How does bracketing related properties and

methods within a defined block of code lead to a "disconnection"?



As defining subroutines and functions leads to even a greater

"disconnection" I can only assume your advice is to avoid them as well.



-ralph





-

"Ralph" <nt_consulting64@yahoo.com>wrote in message

in line -



Sorry about this! I appreciate for you guys this is old stuff but thanks for

bearing with those of us who have come to VB more recently (me from VBA).



Relief!



I often use a construct similar to your suggestion. My work is mainly with

Excel which as I'm sure you know has a multi layer object hierarchy. Some of

these objects types are intrinsically slow to read (and very slow to write).

In certain types of long loops at various object levels I find setting a

temporary object ref' slows things down, and removing the dots using With

speeds things up.



I'm not looking for that last click but to reduce anything that goes beyond

a perceptible delay. I am trying to take a balanced approach to clarity and

speed, though safety is prerequisite.



Thanks again for your comments,

Peter T





-

"Steve Barnett" <noname@nodomain.com>wrote in message

Thanks for your detailed reply



I am certainly concerned to remove any bugs related to use of With,

especially non obvious memory bloat. I think at one stage I experienced that

before ensuring I always execute End With.



My original use of With was indeed to reduce typing and for me I found it

also added clarity. However as I mention in my reply to Ralph I find use of

With and minimizing those dots significantly helps speed up certain types of

long loops.



I will continue to use With but on reading both yours and Ralph's comments I

will be doubly careful.



Regards,

Peter









-

"Ralph" <nt_consulting64@yahoo.com>wrote in message

I forgot in my reply to Steve to ask same, indeed it relates to my first

post in this thread about getting to the bottom of potential problems of

With...End With



Regards,

Peter T





-

"Peter T" <peter_t@discussions>wrote in message





There still is a performance advantage to using the 'With...End With'

construct within (there is a pun there I think) Office VBA.



It is an ancient debate, but one can always learn something new. I always

thought the opposition to the construct was based on performance alone.

However, according to another post, apparently some are annoyed by its

encapsulating qualities and reduced typing.



What is programming if not a balanced approach to clarity, speed, and

safety? There is little that doesn't represent a trade-off. Problem is of

course - one person's "good practice" is ALWAYS somebody else's "vile

odorous hack". <g>



-ralph





-

"Ralph" <nt_consulting64@yahoo.com>wrote in message

Prety much what we've been discussing in this thread... code that works on

one machine and fails on another machine, where you can't see any obvious

difference. I've even had apps that work on one machine at the beginning of

the week and are failing days or weeks later. A reboot fixes them

(sometimes).



I can't be more specific, because the errors, by their very nature, aren't

that predictable.



With Word, I've had automation commands that are processing data in a loop

and that will work for dozens of iterations and will then fail for no

apparent reason. I use the usual developer get-out and ask if they can

reproduce the problem and, more often than not, they can't or it happens in

a different place. I generaly put it down to "load ont he machine" and told

the users to close a few apps before trying again.



This solution is utterly unacceptable, so I started playing around and, at

some stage, removed the With statements. Removing the With fixed the issue.





It's seen two things that led me to this... a piece of code that was setting

the properties of a zip ActiveX. It started with a With statement and went

on for 70 lines before the End With. In and of itself, that's probably not a

problem, but I couldn't get on with this style. If I can't see the With

statement within one scroll of the screen, then it's too far away from what

I'm doing.



The other example was written by one of our contract developers where there

were only 20 (roughly) items in the list, but there was a With nested within

another With. Perfectly acceptable. The fun began when he commented out one

of the With statements in a debugging session and missed one of the

properties. Debugging took somewhat longer than he expected.



It's only my opinion and my coding style, but I prefer the visibility

offered by having to name the object you're referring to.



Steve





-

"Ralph" <nt_consulting64@yahoo.com>wrote in message

I don't remember saying I was "annoyed" at anything, nor can you take what i

am saying to represent anyone elses opinions in this matter. It's a matter

of personal style. I have no problems with other people using this way of

doing things, I just prefer not to for the reasons I stated. If I come

across a time critical operation that can be improved using With, I will

consider it and consider it's context (i.e. it is in any way related to

automation of DLL calls). Please do not twist what I say.



Steve







-

Steve,



Just to confirm what you said and what I had in the back of my mind wrt

'With'. Here's the reference to the original PRB: sheet from M$

support.microsoft.com/kb/q189618/.">support.microsoft.com/kb/q189618/. It was originally published in

1999 (!) but it's been hijacked by XP/Word 2000 descriptions but the

resolution for the problem is the same.



Martin





"Steve Barnett" <noname@nodomain.com>wrote in message



-

I feel so old now... but at least my memory seems to be working, so there's

life left yet!



Thanks Martin.



Steve



"Martin Walke" <martin.walke_no_spam@vega_dot_co_dot_uk>wrote in message