The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Question about references in VB

I am experimenting with Office automation and I am wondering about versions.
If I use Word and want to receive events, I have to have a project reference to the Word library. Everything works as planned, events arrive as expected, but what if I run the same program on a differenc machine with a different version of Word, assuming I use only those features that both versions support?
I would have expected at worst the creation of the application object (word.application) to fail with, returning an error.
But trying to run the application on a different machine gave no such error, instead it did not even run. From debugging info it did not even seem to reach the first instruction.
Sadly, I have no direct access to a machine with a different version of Word, let alone one with a development environment to experiment.

Any hopes of solving this?
Practical Geezer
Monday, January 03, 2005
 
 
It depends on the registry entry you use to 'connect' to word.  If you use the vanilla "word.application", then you probably need to next check the version of word that starts up.

The problem in VB is that the 'type libraries' you link to and use in debugging are probably different for the new version of Word.  Thus some of your ActiveX calls for the new Word don't match the old Word -- and VB silently hangs in this case.

I suppose there should be an ActiveX time-out in there somewhere, though.
AllanL5
Monday, January 03, 2005
 
 
I would think that it should work *if* the newer Office supports the same interfaces as the old Office.  (It would probably also support other, newer, interfaces as well.)  Interfaces in COM are supposed to immutable, and even though the implementation might change, if it supports the same ones (check guids), then it should work.

YMMV, of course.
Aaron F Stanton Send private email
Monday, January 03, 2005
 
 
The trick, or solution is to use late binding. For some strange reason, a large portion of Vb developers have not learned this simple lesson. However, simply put, you can develop with references set (to word, or Excel, or whatever you are using). However, once you get it all working (and have enjoyed syntax checking at compile time, and also inteli-sense during development), you then remove your references, and use late binding.

Using late binding means your code will run will most versions of office (the last 4 versions is a good bet, and I never had something break). The level of compatible for the last 4 versions of word for example is very good. So, with late binding, your code should run just fine with office 97, 2000,2002, 2003.

If you actually set a reference to word (or whatever), then simply moving your software to another pc likely will cause it to break. So, just use late binding, and all well be well.


Albert D. Kallal
Edmonton, Alberta Canada
kallal@msn.com
http://www.members.shaw.ca/AlbertKallal//index.html
Albert D. Kallal Send private email
Monday, January 03, 2005
 
 
I've learnt the late binding lesson Albert!! From you, IIRC.

To the OP, Albert is right, late binding is your friend. It's meant to make things a bit slower, but if you're dealing with Word the slowness of Word itself will _drown_ any speed difference between early and late binding.
Mike MacSween
Monday, January 03, 2005
 
 
As Albert says, late binding is a good general solution to this problem.

If you still prefer to use early binding then the trick is to reference, on your development PC, the earliest version of Word that you want to support. An application with references setup like this should then work with the specified version of Word and any later versions of Word that you encounter on other PCs. It will not work with earlier versions of Word.
Mike Green Send private email
Monday, January 03, 2005
 
 
Well, I already knew about late binding, but thanks anyway. The problem is, with late binding you don't get events, do you? If so, I haven't found out yet how.

And I would really like to have events. So far I have been using late binding, which at least made the application work on any machine with Word, regardless of version.

The development machine has Word 2003 with no option to install an earlier release. So early binding has me link to the Word 11 library and even though I use only features that Word 10 or 9 support too, running on a machine with Word 10 causes trouble.

So, in conclusion, I am still stuck with late binding and no events. I solve the events bit by having a Word template and some VBA to process the events in Word, but that too has drawbacks. Apparently, macros do not get executed if an application was started by another application, as opposed to started by launching it manually.
Practical Geezer
Tuesday, January 04, 2005
 
 
I don't understand what you mean by events. Could you give me for instance.
Mike MacSween
Tuesday, January 04, 2005
 
 
Well,

When Word creates a new document, or when the user requests a document to be printed, Word automation produces an event.
VBA can be used to intercept the event and do some processing.

I intercept the print event to add a record to the systems database that a document has been printed. Another application processes the record to remove the task and reminder to print the document from the task list.

Right now, the event processing code is in the template with which the document is created, so that the record is is always added to the database.

But, I also want to be able to intercept the event in my application, so I might provide additional feedback to the user.
With late binding, this appears to be impossible.
Practical Geezer
Tuesday, January 04, 2005
 
 
I thought you could declare a 'new' Word object "WITH EVENTS".  That would then connect with your event handlers, no?
AllanL5
Tuesday, January 04, 2005
 
 
Yes, but that works only with early binding. And early binding leads to the problems mentioned before, namely version dependencies.
Practical Geezer
Tuesday, January 04, 2005
 
 
'Well,

When Word creates a new document, or when the user requests a document to be printed, Word automation produces an event.
VBA can be used to intercept the event and do some processing.

I intercept the print event to add a record to the systems database that a document has been printed. Another application processes the record to remove the task and reminder to print the document from the task list.

Right now, the event processing code is in the template with which the document is created, so that the record is is always added to the database.

But, I also want to be able to intercept the event in my application, so I might provide additional feedback to the user.
With late binding, this appears to be impossible.'

I see. I know what events are in Access, VBA etc., just never thought about using them with Word automation. I've never bothered doing anything with 'this has been printed' things. There seem to be too many things to go wrong at the printing end to make it reliable.
Mike MacSween
Tuesday, January 04, 2005
 
 
"I've never bothered doing anything with 'this has been printed' things. There seem to be too many things to go wrong at the printing end to make it reliable."

Certainly. Many things can go wrong before the job finishes. But, this is a (wo)manned system. If the job does not finish properly, one is going to notice and print again. Until eventually it succeeds and the document gets sent to the customer. During which many other things may go wrong again.
The system I am working on is only meant to support people, not replace them. The printed status of a document is the best approximation the system has of knowing whether it was sent to the customer. When printing failed, the user will no longer be reminded to send it, but a user does not usually print a document without the intent to do something with it. So once they started printing it, it is very unlikely that the document will not be sent.
Practical Geezer
Tuesday, January 04, 2005
 
 
Sure. Just that I personally haven't (yet) done anything with the OnPrint event of a Word documnent (I'm just guessing that that's what the event is, by the way).

I haven't really had a pressing need for it in an app I've done, and whenever I've thought about it I've always imagined all the, 'what if there's a paper jam', 'what if it's sent to the wrong tray', 'what if the printer is off-line', 'what if the user sends it to a different printer', 'what if the dog eats it as it comes out of the printer'
Mike MacSween
Tuesday, January 04, 2005
 
 
1.  Create a dll for each version of Word that your planning on supporting.  These dlls will contain whatever code your trying to run but would reference a different version of Word.
2.  Create a class in your executing application that can determine which version of Word is install on the machine.  When the corect version has been found you will the class will then call one of the dll in step 1.

It seems like alot work but this is the only I gotten my office code to work correctly.

JH
JH Send private email
Thursday, January 06, 2005
 
 
Thanks JH

Right now that probably is overkill for my situation. Meaning that the price of not having events is smaller than that of implementing your suggestion, but I will keep it in mind, so that I can re-evaluate as soon as the no-events price goes up :-)
Practical Geezer
Friday, January 07, 2005
 
 
In my experience, it is only necessary to code against and reference the single earliest version of Word that needs to be supported.

Deploying an application built in this way to a machine with the same or a later version of Word then just works fine:

http://support.microsoft.com/kb/244167

So if you have, for example, Word 2000 installed and referenced on your development machine then you can deploy to machines with Word 2000, Word 2002 or Word 2003. The problem that the OP has is that he doesn't have the option to downgrade his development machine from Word 2003 to an earlier version. So none of these solutions that require referencing older versions of Word will work for him.

In the .NET world, the Primary Interop Assemblies provide an approach that covers both Word 2002 and Word 2003. This might be worth investigating if the need is to use Visual Basic .NET:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnoxpta/html/odc_oxppias.asp
Mike Green Send private email
Friday, January 07, 2005
 
 
The OP is correct, with events can’t be used with late binding.

However, the fact that you need to consume the objects (word) events means that in theory  you could reverse this, and have word automate YOUR application. This does mean that you would have to have code in the word template, but it sounds like you do anyway. You could still have your system launch word, but in fact if code is going to be in the word template, then this whole thing could work EVEN WHEN the user does not even launch your application. The users would just have to launch the word document, and it would thus inform your code via automation.


Albert D. Kallal
Edmonton, Alberta Canada
kallal@msn.com
http://www.members.shaw.ca/AlbertKallal/index.html
Albert D. Kallal Send private email
Sunday, January 09, 2005
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz