Word Menus After Automation

[Leigh P]

Hi there

After exectuting a series of automation commands (from Access, either as a
direct mailmerge - or a sequence of involved actions to perform a similar
function) versions of Word after 97 often end up with their menus
unresponsive to mouse clicks.
If the user then causes the new Word document to lose the focus to another
window - then regaining it frees up the menus to begin operating normally.

Does anyone have any experience as to why this might be happening - or
better yet, just a plain ol' work around?

Users shouldn't be subjected to this inconvenience - especially since it
didn't used to happen under 97 (so perhaps has something to do with the
multiple windows and MDI of Word since?)

Any advice would be great.

Thanks

Leigh

 

[Howard Kaikow]

You'd have someone look at the actual Access code used to determine effects
on Word.
Macros from Office 97 often need to be revised to handle the SDI/MDI change.
For example, see the SDI example at
http://www.standards.com/OhMyWord/VBACodeSnippets.html.

 

[Leigh P]

The snippet I needed was near enough in there - accomplished close enough to
what I want.
No API's required even (as have gone down that road with this before!)

Many thanks

 

[Howard Kaikow]

Ayup, that's a valuable piece of code.
Took me 3 loooong daze to figure it out, code and test.

I only tested code in Word 2000.

 

[Leigh P]

Seems my success was short lived.

I'd essentially tried to work around my problem by shifting the focus from
the latest window (using code found in that template - simply 'Activating' a
document/window) to another - and then my document's menus could be found
working again (as if done through the UI).

However, activating a document isn't proving as reliable for my circumstance
as it does when looping through the documents in the example template.
I wasn't actually *solving* the problem - but that wasn't terribly
important, but now that I find it isn't even consistent...

The template itself uses API calls to force an on screen dialog to shift
parent window - so that the active document displays it as you loop through.
However - in wanting *menu bars* to be able to somehow come through, I've
felt I have to concentrate on what Word's doing.

I'm not sure where to go from here.

Any advice?

Does Microsoft acknowledge this problem that anyone knows of?

Many thanks

 

[Howard Kaikow]

Activating may not be enough.
You may have to mess around with windows handles.

 

[Leigh P]

I've tried Putfocus in the past - but with little success.
Doesn't seem to force the focus to the required document.

The template that was mentioned, deals well with setting a parent window...
but I have no object to set the parent of.

Any other window manipulating API's that I might try?

Many thanks

 

[Howard Kaikow]

Without analyzing your code, it's hard to give further advice.
A solution might be easy or very difficult.

The issue, at least in the example I posted, was not the focus, rather it is
a question of parentage.

 

[Leigh P]

Absolutely - I agree.

I've used the SetForegroundWindow API now - with much better success.
Unlike Putfocus it doesn't require the running code to be in the same
thread - so yippee.
Super dooper.

Unfortuately we are still in workaround country - rather than genuine issue
fix - but since I can't find any instance of Microsoft admitting to this as
an issue at all...
Which is suprising - as I'm getting reports of it as an issue at many
clients - and not just using alternative mailmerge methods.

Oh well - there's a way onwards at least

Thanks again.