Word Automation (Access 97)

Topic

New Reply

I’m using WordAutomation to print form letters. The basic program logic is as follows:

Create Word object, opening minimized and visible
   Read each record from recordset, and do following:
      Create new letter from template.
      Resolve boomarks.
      Print letter.
      Close letter without saving.
 When finished with all letters, close Word Object.

This works fine. However, I also have an Preview alternative in which the user can review/change each letter prior to printing. The Word object is not minimized, and I have a msgbox insert prior to the Print command.

This works also, but requires 1 cosmetic change. When the Word object is opened, it becomes the current window object. So the first letter displays on the screen, and the Access message box displays on top of that, which I like. However, as soon as I make a selection from the msgbox, Access becomes the current application again, and the next letter doesn’t actually show on the screen because it is behind Access. How do I make the Word Object move back on top when the next letter opens? I suppose I could keep closing/opening word object itself, but that would slow-down processing too much.

Reply | Quote

Replies

Hi Mark,
Have you tried something like
appWord.Activate?
Hope that helps.

Reply | Quote

The .Activate definitely moves Word to the top, but the Access message box no longer displays on top of the document. The Access button on the taskbar does blink; which I guess indicates that it is waiting for a response in its message box. Having the Access message box on top of the Word document is a nice effect, and I’d like to be able to keep doing it after the first one.

Reply | Quote

Mark,

Could you open the Message Box using acDialog? That might cause the code to wait for a response from the user. Then, continuing with .Activate so Word comes up…

Tom

Reply | Quote

I’m beginning to think it is a fluke that the message box appears over the letter the first time through, since it doesn’t seem to always do it! It may be some sort of timing issue. I’m thinking I may just keep Word minimized, and let Users bring it to front if they want.

Reply | Quote

Hi Mark,
How does your code handle the changes being made to the created document – e.g. what happens if the user changes it, prints it and closes the app rather than just the document?
Ignoring that, I guess it shoud be possible to reactivate your access window, minimized if necessary, to display the message box once again, then reactivate Word and so on. Otherwise, I guess you could simply create each word document with your code and leave them open for revision afterwards without printing any of them automatically.
Does that help?

Reply | Quote

>>How does your code handle the changes being made to the created document – e.g. what happens if the user changes it, prints it and closes the app rather than just the document?<<

I just put a "On Error Resume Next" to handle my trying to close a document that has already been closed. But you do raise a good point as to what to do if user closes Word. I'll have to re-examine that.

Reply | Quote

This may be a longshot, but could you call the MsgBox from within Word and just pass the answer back to Access?

I’ve done some pretty heavy automation of Excel from Access and I’ve usually called MsgBoxes from within Excel once it is the Active App. That always seems to work well for me.

HTH

Reply | Quote

>>but could you call the MsgBox from within Word and just pass the answer back to Access?<<

I don't know, I've never tried to do anything like that so I wouldn't know where to begin. Anyway, I'm guessing that once the Access message box was called, it would make Access the active app, and bring it to the front.

Reply | Quote

Hi Mark,
Assuming you’re doing this in a loop, if you add 65536 to the vbMsgBoxStyle value (e.g. MsgBox “Test”, 65539 will give you Yes, No, Cancel) then the message box should become the foreground window. Using appWord.Activate will then bring word to the foreground for editing etc.
Hope that helps.

Reply | Quote

>>65536 to the vbMsgBoxStyle value (e.g. MsgBox “Test”, 65539 will give you Yes, No, Cancel) <<

Do you actually remember the numeric values? I find it easier to remember vbYesNoCancel.

But the situation I was describing can't really be done, I found out. I wanted to know why the Access message box floated over the Word document for the first document, but not for subsequent documents. It turns out that my code in Access was such that I was actually opening the Word document and popping the message box BEFORE the rest of the Access screen was displayed! (That is, it all happened before the first Current event processed) So, while Access was displaying in front of Word, the only thing to display at that time was the message box. After that, the Access form was finally displayed, so the next time it became active, it covered Word.

Reply | Quote

Child windows won’t appear infront of an App that they don’t belong to EXCEPT if the Z-order is modified to set them as a topmost window whne it will appear in front of any window that is not a topmost window.
If you do require behaviour that the message appears in front of both Access/Word then you may find it easiest to create a dll containg your special messagebox and use automation to put Access in front of word or vice versa before calling the special message box.

Reply | Quote

I found out why the first letter exhibited the behavior of floating the Access message box above the Word document. It was because the rest of the Access form hadn’t displayed yet. A form doesn’t display until AFTER the first Current event, and the message box got displayed first. Anyway, I’ve decided to keep the Word document minimized, which allows user to select it if they want.

Thanks.

Reply | Quote