HELP!! uncovering hidden dialog box

[TC]

Hi Folks

I've been trying to solve the following problem on & off for about 6 weeks.

If anyone can shed any light on it, I'd be very appreciative!

I'm trying to print a document from MS Access 97 VBA using automation to MS
Word 97. I'm assuming the problem is Windows/VBA related, not Access
related, and would therefore happen in VB also. Hence my desperate resort
to this newsgroup!

Here's the VBA I'm using:

Public Sub doit()
Dim oWord As Object
Set oWord = CreateObject("word.application")
oWord.Documents.Open "C:\TEST.doc"
'MsgBox "BLAH" ' [A]
'oWord.Visible = True ' [B]
oWord.PrintOut Background:=True
' [C]
MsgBox "OK"
oWord.Quit 0 ' 0=discard changes.
Set oWord = Nothing
End Sub

The document in question has a margin set outside the printable area of the
page. This can be achieved by opening any document, going to page preview
mode, dragging the top margin right up close to the top of the page, then
saving the document & exitting Word. Printing the document (in the normal
way from Word) should display a dialog box: "The margins of section 1 are
set outside the printable area of the page. Do you want to continue?
[Yes]/[No]".

When I run this sub from the Access IDE, the dialog box noted above is
displayed BELOW the Access IDE – not ABOVE it – so it is not visible - so
the user does not know it's there, and can not answer it. The sub then
appears to hang. Any reference in the sub to any method or property of the
oWord object, will hang (eg. oWord.Quit). Even trying to set
oWord.Visible=True will hang.

I concluded that I needed, on return from the .PrintOut call, to detect
whether Word had displayed a dialog box, and if so, bring it to the
foreground (using API calls, not oWord methods or properties) so the user
could answer it.

I confirmed that the oWord.PrintOut statement returns immediately to point
[C] before the dialog box has been displayed. I wrote some code to wait for
a second or two at that point, then look for the dialog box with
FindWindow("#32770","Microsoft Word"). This code successfully found (&
returned the handle to) the relevant dialog box.

However, I can not then (for the life of me) swap to the dialog box in such
a way that everything continues ok when the user answers it! I've tried:
BringWindowToTop on every conceivable window handle including the Word main
window handle, the dialog box window handle, the dialog box OK button
window handle, and so on;
SetForeGroundWindow ditto;
Access VBA AppActivate on the Word window caption, and
Many & varied combinations of the above!

Whatever I do, the following happens:
My code makes the dialog box appear (with or without the Word main window);
The dialog box lets me click Yes or No;
Someone (presumably Word or Windows) repaints the screen area that the
dialog box overlayed, but then:
MS Word hangs! Its window is still displayed, but it doesn't respond to any
keystrokes, mouse clicks, dragging actions or whatever.
Then the Access IDE hangs: sometimes showing a popup message that MS Word
is not responding, and sometimes not.

And here's the rub! :-

If I include statement [A] or [B], it all works fine! (ie. nothing hangs).
If I don't include them, it hangs as described above!

I've checked GetActiveWindow() at various points (with and without
statements [A] and [B]) but this always points to the Access IDE window.

This is driving me A*B*S*O*L*U*T*E*L*Y M*E*N*T*A*L.

Can anyone help me on this please.

Thanks,
TC

[TC]

TC <no@email.please> wrote in article
<01c02a2e$bf913280$15fb98cb@pentium>...
> I've checked GetActiveWindow() at various points ...


I mean GetForeGroundWindow().

TC

[TC]

TC <no@email.please> wrote in article
<01c02a2e$bf913280$15fb98cb@pentium>...
> I've checked GetActiveWindow() at various points ...


I mean GetForeGroundWindow().

TC

[Mark Alexander Bertenshaw]

TC -

I have pasted this code into both VB 5 and Access 97, and it seems to work!!

BTW I am using Windows 98. What are you using?

--
Mark Alexander Bertenshaw
Programmer/Analyst
PrimeResponse
Brentford
UK

"TC" <no@email.please> wrote in message
news:01c02a2e$bf913280$15fb98cb@pentium...
> Hi Folks
>
> I've been trying to solve the following problem on & off for about 6
weeks.
>
> If anyone can shed any light on it, I'd be very appreciative!
>
> I'm trying to print a document from MS Access 97 VBA using automation to
MS
> Word 97. I'm assuming the problem is Windows/VBA related, not Access
> related, and would therefore happen in VB also. Hence my desperate resort
> to this newsgroup!
>
> Here's the VBA I'm using:
>
> Public Sub doit()
> Dim oWord As Object
> Set oWord = CreateObject("word.application")
> oWord.Documents.Open "C:\TEST.doc"
> 'MsgBox "BLAH" ' [A]
> 'oWord.Visible = True ' [B]
> oWord.PrintOut Background:=True
> ' [C]
> MsgBox "OK"
> oWord.Quit 0 ' 0=discard changes.
> Set oWord = Nothing
> End Sub
>
> The document in question has a margin set outside the printable area of
the
> page. This can be achieved by opening any document, going to page preview
> mode, dragging the top margin right up close to the top of the page, then
> saving the document & exitting Word. Printing the document (in the normal
> way from Word) should display a dialog box: "The margins of section 1 are
> set outside the printable area of the page. Do you want to continue?
> [Yes]/[No]".
>
> When I run this sub from the Access IDE, the dialog box noted above is
> displayed BELOW the Access IDE - not ABOVE it - so it is not visible - so
> the user does not know it's there, and can not answer it. The sub then
> appears to hang. Any reference in the sub to any method or property of the
> oWord object, will hang (eg. oWord.Quit). Even trying to set
> oWord.Visible=True will hang.
>
> I concluded that I needed, on return from the .PrintOut call, to detect
> whether Word had displayed a dialog box, and if so, bring it to the
> foreground (using API calls, not oWord methods or properties) so the user
> could answer it.
>
> I confirmed that the oWord.PrintOut statement returns immediately to point
> [C] before the dialog box has been displayed. I wrote some code to wait
for
> a second or two at that point, then look for the dialog box with
> FindWindow("#32770","Microsoft Word"). This code successfully found (&
> returned the handle to) the relevant dialog box.
>
> However, I can not then (for the life of me) swap to the dialog box in
such
> a way that everything continues ok when the user answers it! I've tried:
> BringWindowToTop on every conceivable window handle including the Word
main
> window handle, the dialog box window handle, the dialog box OK button
> window handle, and so on;
> SetForeGroundWindow ditto;
> Access VBA AppActivate on the Word window caption, and
> Many & varied combinations of the above!
>
> Whatever I do, the following happens:
> My code makes the dialog box appear (with or without the Word main
window);
> The dialog box lets me click Yes or No;
> Someone (presumably Word or Windows) repaints the screen area that the
> dialog box overlayed, but then:
> MS Word hangs! Its window is still displayed, but it doesn't respond to
any
> keystrokes, mouse clicks, dragging actions or whatever.
> Then the Access IDE hangs: sometimes showing a popup message that MS Word
> is not responding, and sometimes not.
>
> And here's the rub! :-
>
> If I include statement [A] or [B], it all works fine! (ie. nothing hangs).
> If I don't include them, it hangs as described above!
>
> I've checked GetActiveWindow() at various points (with and without
> statements [A] and [B]) but this always points to the Access IDE window.
>
> This is driving me A*B*S*O*L*U*T*E*L*Y M*E*N*T*A*L.
>
> Can anyone help me on this please.
>
> Thanks,
> TC
>

[Mark Alexander Bertenshaw]

TC -

I have pasted this code into both VB 5 and Access 97, and it seems to work!!

BTW I am using Windows 98. What are you using?

--
Mark Alexander Bertenshaw
Programmer/Analyst
PrimeResponse
Brentford
UK

"TC" <no@email.please> wrote in message
news:01c02a2e$bf913280$15fb98cb@pentium...
> Hi Folks
>
> I've been trying to solve the following problem on & off for about 6
weeks.
>
> If anyone can shed any light on it, I'd be very appreciative!
>
> I'm trying to print a document from MS Access 97 VBA using automation to
MS
> Word 97. I'm assuming the problem is Windows/VBA related, not Access
> related, and would therefore happen in VB also. Hence my desperate resort
> to this newsgroup!
>
> Here's the VBA I'm using:
>
> Public Sub doit()
> Dim oWord As Object
> Set oWord = CreateObject("word.application")
> oWord.Documents.Open "C:\TEST.doc"
> 'MsgBox "BLAH" ' [A]
> 'oWord.Visible = True ' [B]
> oWord.PrintOut Background:=True
> ' [C]
> MsgBox "OK"
> oWord.Quit 0 ' 0=discard changes.
> Set oWord = Nothing
> End Sub
>
> The document in question has a margin set outside the printable area of
the
> page. This can be achieved by opening any document, going to page preview
> mode, dragging the top margin right up close to the top of the page, then
> saving the document & exitting Word. Printing the document (in the normal
> way from Word) should display a dialog box: "The margins of section 1 are
> set outside the printable area of the page. Do you want to continue?
> [Yes]/[No]".
>
> When I run this sub from the Access IDE, the dialog box noted above is
> displayed BELOW the Access IDE - not ABOVE it - so it is not visible - so
> the user does not know it's there, and can not answer it. The sub then
> appears to hang. Any reference in the sub to any method or property of the
> oWord object, will hang (eg. oWord.Quit). Even trying to set
> oWord.Visible=True will hang.
>
> I concluded that I needed, on return from the .PrintOut call, to detect
> whether Word had displayed a dialog box, and if so, bring it to the
> foreground (using API calls, not oWord methods or properties) so the user
> could answer it.
>
> I confirmed that the oWord.PrintOut statement returns immediately to point
> [C] before the dialog box has been displayed. I wrote some code to wait
for
> a second or two at that point, then look for the dialog box with
> FindWindow("#32770","Microsoft Word"). This code successfully found (&
> returned the handle to) the relevant dialog box.
>
> However, I can not then (for the life of me) swap to the dialog box in
such
> a way that everything continues ok when the user answers it! I've tried:
> BringWindowToTop on every conceivable window handle including the Word
main
> window handle, the dialog box window handle, the dialog box OK button
> window handle, and so on;
> SetForeGroundWindow ditto;
> Access VBA AppActivate on the Word window caption, and
> Many & varied combinations of the above!
>
> Whatever I do, the following happens:
> My code makes the dialog box appear (with or without the Word main
window);
> The dialog box lets me click Yes or No;
> Someone (presumably Word or Windows) repaints the screen area that the
> dialog box overlayed, but then:
> MS Word hangs! Its window is still displayed, but it doesn't respond to
any
> keystrokes, mouse clicks, dragging actions or whatever.
> Then the Access IDE hangs: sometimes showing a popup message that MS Word
> is not responding, and sometimes not.
>
> And here's the rub! :-
>
> If I include statement [A] or [B], it all works fine! (ie. nothing hangs).
> If I don't include them, it hangs as described above!
>
> I've checked GetActiveWindow() at various points (with and without
> statements [A] and [B]) but this always points to the Access IDE window.
>
> This is driving me A*B*S*O*L*U*T*E*L*Y M*E*N*T*A*L.
>
> Can anyone help me on this please.
>
> Thanks,
> TC
>

[TC]

Mark

Thanks for your reply.

I'm using Access 97 on Windows 95 version 4.00.950b (the OEM version).

I try to test all my code on w95, 98, NT & 2000, but I'm still stuck
getting this to work on w95!

The only fact that I omitted (because I hoped it was irrelevant), is this.
I don't have a printer on the PC that I'm testing this from. When the code
executes the .PrintOut method, a dialog box comes up from Microsoft FAX
(which I assume is the default print driver) saying that there is an error.
This dialog box IS forced to the front. The .PrintOut call does NOT return
yet. When I OK that dialog box, the .PrintOut call returns, and the rest of
the problem occurs as described - in particular, the "Margins are
outside..." dialog box is displayed "behind the scenes" (not forced to the
front).

Does this give you any extra clues?

Are you sure your document is producing the required error? ("Margins are
outside... etc.").

Thanks again,
TC



Mark Alexander Bertenshaw <mark.bertenshaw@virgin.net> wrote in article
<39d54d54@news.devx.com>...
> TC -
>
> I have pasted this code into both VB 5 and Access 97, and it seems to
work!!
>
> BTW I am using Windows 98. What are you using?
>
> --
> Mark Alexander Bertenshaw
> Programmer/Analyst
> PrimeResponse
> Brentford
> UK
>
> "TC" <no@email.please> wrote in message
> news:01c02a2e$bf913280$15fb98cb@pentium...
> > Hi Folks
> >
> > I've been trying to solve the following problem on & off for about 6
> weeks.
> >
> > If anyone can shed any light on it, I'd be very appreciative!
> >
> > I'm trying to print a document from MS Access 97 VBA using automation
to
> MS
> > Word 97. I'm assuming the problem is Windows/VBA related, not Access
> > related, and would therefore happen in VB also. Hence my desperate
resort
> > to this newsgroup!
> >
> > Here's the VBA I'm using:
> >
> > Public Sub doit()
> > Dim oWord As Object
> > Set oWord = CreateObject("word.application")
> > oWord.Documents.Open "C:\TEST.doc"
> > 'MsgBox "BLAH" ' [A]
> > 'oWord.Visible = True ' [B]
> > oWord.PrintOut Background:=True
> > ' [C]
> > MsgBox "OK"
> > oWord.Quit 0 ' 0=discard changes.
> > Set oWord = Nothing
> > End Sub
> >
> > The document in question has a margin set outside the printable area of
> the
> > page. This can be achieved by opening any document, going to page
preview
> > mode, dragging the top margin right up close to the top of the page,
then
> > saving the document & exitting Word. Printing the document (in the
normal
> > way from Word) should display a dialog box: "The margins of section 1
are
> > set outside the printable area of the page. Do you want to continue?
> > [Yes]/[No]".
> >
> > When I run this sub from the Access IDE, the dialog box noted above is
> > displayed BELOW the Access IDE - not ABOVE it - so it is not visible -
so
> > the user does not know it's there, and can not answer it. The sub then
> > appears to hang. Any reference in the sub to any method or property of
the
> > oWord object, will hang (eg. oWord.Quit). Even trying to set
> > oWord.Visible=True will hang.
> >
> > I concluded that I needed, on return from the .PrintOut call, to detect
> > whether Word had displayed a dialog box, and if so, bring it to the
> > foreground (using API calls, not oWord methods or properties) so the
user
> > could answer it.
> >
> > I confirmed that the oWord.PrintOut statement returns immediately to
point
> > [C] before the dialog box has been displayed. I wrote some code to wait
> for
> > a second or two at that point, then look for the dialog box with
> > FindWindow("#32770","Microsoft Word"). This code successfully found (&
> > returned the handle to) the relevant dialog box.
> >
> > However, I can not then (for the life of me) swap to the dialog box in
> such
> > a way that everything continues ok when the user answers it! I've
tried:
> > BringWindowToTop on every conceivable window handle including the Word
> main
> > window handle, the dialog box window handle, the dialog box OK button
> > window handle, and so on;
> > SetForeGroundWindow ditto;
> > Access VBA AppActivate on the Word window caption, and
> > Many & varied combinations of the above!
> >
> > Whatever I do, the following happens:
> > My code makes the dialog box appear (with or without the Word main
> window);
> > The dialog box lets me click Yes or No;
> > Someone (presumably Word or Windows) repaints the screen area that the
> > dialog box overlayed, but then:
> > MS Word hangs! Its window is still displayed, but it doesn't respond to
> any
> > keystrokes, mouse clicks, dragging actions or whatever.
> > Then the Access IDE hangs: sometimes showing a popup message that MS
Word
> > is not responding, and sometimes not.
> >
> > And here's the rub! :-
> >
> > If I include statement [A] or [B], it all works fine! (ie. nothing
hangs).
> > If I don't include them, it hangs as described above!
> >
> > I've checked GetActiveWindow() at various points (with and without
> > statements [A] and [B]) but this always points to the Access IDE
window.
> >
> > This is driving me A*B*S*O*L*U*T*E*L*Y M*E*N*T*A*L.
> >
> > Can anyone help me on this please.
> >
> > Thanks,
> > TC
> >
>
>
>

[TC]

Mark

Thanks for your reply.

I'm using Access 97 on Windows 95 version 4.00.950b (the OEM version).

I try to test all my code on w95, 98, NT & 2000, but I'm still stuck
getting this to work on w95!

The only fact that I omitted (because I hoped it was irrelevant), is this.
I don't have a printer on the PC that I'm testing this from. When the code
executes the .PrintOut method, a dialog box comes up from Microsoft FAX
(which I assume is the default print driver) saying that there is an error.
This dialog box IS forced to the front. The .PrintOut call does NOT return
yet. When I OK that dialog box, the .PrintOut call returns, and the rest of
the problem occurs as described - in particular, the "Margins are
outside..." dialog box is displayed "behind the scenes" (not forced to the
front).

Does this give you any extra clues?

Are you sure your document is producing the required error? ("Margins are
outside... etc.").

Thanks again,
TC



Mark Alexander Bertenshaw <mark.bertenshaw@virgin.net> wrote in article
<39d54d54@news.devx.com>...
> TC -
>
> I have pasted this code into both VB 5 and Access 97, and it seems to
work!!
>
> BTW I am using Windows 98. What are you using?
>
> --
> Mark Alexander Bertenshaw
> Programmer/Analyst
> PrimeResponse
> Brentford
> UK
>
> "TC" <no@email.please> wrote in message
> news:01c02a2e$bf913280$15fb98cb@pentium...
> > Hi Folks
> >
> > I've been trying to solve the following problem on & off for about 6
> weeks.
> >
> > If anyone can shed any light on it, I'd be very appreciative!
> >
> > I'm trying to print a document from MS Access 97 VBA using automation
to
> MS
> > Word 97. I'm assuming the problem is Windows/VBA related, not Access
> > related, and would therefore happen in VB also. Hence my desperate
resort
> > to this newsgroup!
> >
> > Here's the VBA I'm using:
> >
> > Public Sub doit()
> > Dim oWord As Object
> > Set oWord = CreateObject("word.application")
> > oWord.Documents.Open "C:\TEST.doc"
> > 'MsgBox "BLAH" ' [A]
> > 'oWord.Visible = True ' [B]
> > oWord.PrintOut Background:=True
> > ' [C]
> > MsgBox "OK"
> > oWord.Quit 0 ' 0=discard changes.
> > Set oWord = Nothing
> > End Sub
> >
> > The document in question has a margin set outside the printable area of
> the
> > page. This can be achieved by opening any document, going to page
preview
> > mode, dragging the top margin right up close to the top of the page,
then
> > saving the document & exitting Word. Printing the document (in the
normal
> > way from Word) should display a dialog box: "The margins of section 1
are
> > set outside the printable area of the page. Do you want to continue?
> > [Yes]/[No]".
> >
> > When I run this sub from the Access IDE, the dialog box noted above is
> > displayed BELOW the Access IDE - not ABOVE it - so it is not visible -
so
> > the user does not know it's there, and can not answer it. The sub then
> > appears to hang. Any reference in the sub to any method or property of
the
> > oWord object, will hang (eg. oWord.Quit). Even trying to set
> > oWord.Visible=True will hang.
> >
> > I concluded that I needed, on return from the .PrintOut call, to detect
> > whether Word had displayed a dialog box, and if so, bring it to the
> > foreground (using API calls, not oWord methods or properties) so the
user
> > could answer it.
> >
> > I confirmed that the oWord.PrintOut statement returns immediately to
point
> > [C] before the dialog box has been displayed. I wrote some code to wait
> for
> > a second or two at that point, then look for the dialog box with
> > FindWindow("#32770","Microsoft Word"). This code successfully found (&
> > returned the handle to) the relevant dialog box.
> >
> > However, I can not then (for the life of me) swap to the dialog box in
> such
> > a way that everything continues ok when the user answers it! I've
tried:
> > BringWindowToTop on every conceivable window handle including the Word
> main
> > window handle, the dialog box window handle, the dialog box OK button
> > window handle, and so on;
> > SetForeGroundWindow ditto;
> > Access VBA AppActivate on the Word window caption, and
> > Many & varied combinations of the above!
> >
> > Whatever I do, the following happens:
> > My code makes the dialog box appear (with or without the Word main
> window);
> > The dialog box lets me click Yes or No;
> > Someone (presumably Word or Windows) repaints the screen area that the
> > dialog box overlayed, but then:
> > MS Word hangs! Its window is still displayed, but it doesn't respond to
> any
> > keystrokes, mouse clicks, dragging actions or whatever.
> > Then the Access IDE hangs: sometimes showing a popup message that MS
Word
> > is not responding, and sometimes not.
> >
> > And here's the rub! :-
> >
> > If I include statement [A] or [B], it all works fine! (ie. nothing
hangs).
> > If I don't include them, it hangs as described above!
> >
> > I've checked GetActiveWindow() at various points (with and without
> > statements [A] and [B]) but this always points to the Access IDE
window.
> >
> > This is driving me A*B*S*O*L*U*T*E*L*Y M*E*N*T*A*L.
> >
> > Can anyone help me on this please.
> >
> > Thanks,
> > TC
> >
>
>
>

[Mark Alexander Bertenshaw]

Mark -

Well, I am in the same position - I didn't have a printer connected either.
And I am positive that I get the "margins are outside ..." message in front.

Sorry - I'm stumped. Why not try a few other OS and machine combinations?

--
Mark Alexander Bertenshaw
Programmer/Analyst
PrimeResponse
Brentford
UK

"TC" <no@email.please> wrote in message
news:01c02aa2$91f38ca0$45fb98cb@pentium...
> Mark
>
> Thanks for your reply.
>
> I'm using Access 97 on Windows 95 version 4.00.950b (the OEM version).
>
> I try to test all my code on w95, 98, NT & 2000, but I'm still stuck
> getting this to work on w95!
>
> The only fact that I omitted (because I hoped it was irrelevant), is this.
> I don't have a printer on the PC that I'm testing this from. When the code
> executes the .PrintOut method, a dialog box comes up from Microsoft FAX
> (which I assume is the default print driver) saying that there is an
error.
> This dialog box IS forced to the front. The .PrintOut call does NOT return
> yet. When I OK that dialog box, the .PrintOut call returns, and the rest
of
> the problem occurs as described - in particular, the "Margins are
> outside..." dialog box is displayed "behind the scenes" (not forced to the
> front).
>
> Does this give you any extra clues?
>
> Are you sure your document is producing the required error? ("Margins are
> outside... etc.").
>
> Thanks again,
> TC
>
>
>
> Mark Alexander Bertenshaw <mark.bertenshaw@virgin.net> wrote in article
> <39d54d54@news.devx.com>...
> > TC -
> >
> > I have pasted this code into both VB 5 and Access 97, and it seems to
> work!!
> >
> > BTW I am using Windows 98. What are you using?
> >
> > --
> > Mark Alexander Bertenshaw
> > Programmer/Analyst
> > PrimeResponse
> > Brentford
> > UK
> >
> > "TC" <no@email.please> wrote in message
> > news:01c02a2e$bf913280$15fb98cb@pentium...
> > > Hi Folks
> > >
> > > I've been trying to solve the following problem on & off for about 6
> > weeks.
> > >
> > > If anyone can shed any light on it, I'd be very appreciative!
> > >
> > > I'm trying to print a document from MS Access 97 VBA using automation
> to
> > MS
> > > Word 97. I'm assuming the problem is Windows/VBA related, not Access
> > > related, and would therefore happen in VB also. Hence my desperate
> resort
> > > to this newsgroup!
> > >
> > > Here's the VBA I'm using:
> > >
> > > Public Sub doit()
> > > Dim oWord As Object
> > > Set oWord = CreateObject("word.application")
> > > oWord.Documents.Open "C:\TEST.doc"
> > > 'MsgBox "BLAH" ' [A]
> > > 'oWord.Visible = True ' [B]
> > > oWord.PrintOut Background:=True
> > > ' [C]
> > > MsgBox "OK"
> > > oWord.Quit 0 ' 0=discard changes.
> > > Set oWord = Nothing
> > > End Sub
> > >
> > > The document in question has a margin set outside the printable area
of
> > the
> > > page. This can be achieved by opening any document, going to page
> preview
> > > mode, dragging the top margin right up close to the top of the page,
> then
> > > saving the document & exitting Word. Printing the document (in the
> normal
> > > way from Word) should display a dialog box: "The margins of section 1
> are
> > > set outside the printable area of the page. Do you want to continue?
> > > [Yes]/[No]".
> > >
> > > When I run this sub from the Access IDE, the dialog box noted above is
> > > displayed BELOW the Access IDE - not ABOVE it - so it is not visible -
> so
> > > the user does not know it's there, and can not answer it. The sub then
> > > appears to hang. Any reference in the sub to any method or property of
> the
> > > oWord object, will hang (eg. oWord.Quit). Even trying to set
> > > oWord.Visible=True will hang.
> > >
> > > I concluded that I needed, on return from the .PrintOut call, to
detect
> > > whether Word had displayed a dialog box, and if so, bring it to the
> > > foreground (using API calls, not oWord methods or properties) so the
> user
> > > could answer it.
> > >
> > > I confirmed that the oWord.PrintOut statement returns immediately to
> point
> > > [C] before the dialog box has been displayed. I wrote some code to
wait
> > for
> > > a second or two at that point, then look for the dialog box with
> > > FindWindow("#32770","Microsoft Word"). This code successfully found (&
> > > returned the handle to) the relevant dialog box.
> > >
> > > However, I can not then (for the life of me) swap to the dialog box in
> > such
> > > a way that everything continues ok when the user answers it! I've
> tried:
> > > BringWindowToTop on every conceivable window handle including the Word
> > main
> > > window handle, the dialog box window handle, the dialog box OK button
> > > window handle, and so on;
> > > SetForeGroundWindow ditto;
> > > Access VBA AppActivate on the Word window caption, and
> > > Many & varied combinations of the above!
> > >
> > > Whatever I do, the following happens:
> > > My code makes the dialog box appear (with or without the Word main
> > window);
> > > The dialog box lets me click Yes or No;
> > > Someone (presumably Word or Windows) repaints the screen area that the
> > > dialog box overlayed, but then:
> > > MS Word hangs! Its window is still displayed, but it doesn't respond
to
> > any
> > > keystrokes, mouse clicks, dragging actions or whatever.
> > > Then the Access IDE hangs: sometimes showing a popup message that MS
> Word
> > > is not responding, and sometimes not.
> > >
> > > And here's the rub! :-
> > >
> > > If I include statement [A] or [B], it all works fine! (ie. nothing
> hangs).
> > > If I don't include them, it hangs as described above!
> > >
> > > I've checked GetActiveWindow() at various points (with and without
> > > statements [A] and [B]) but this always points to the Access IDE
> window.
> > >
> > > This is driving me A*B*S*O*L*U*T*E*L*Y M*E*N*T*A*L.
> > >
> > > Can anyone help me on this please.
> > >
> > > Thanks,
> > > TC
> > >
> >
> >
> >

[Mark Alexander Bertenshaw]

Mark -

Well, I am in the same position - I didn't have a printer connected either.
And I am positive that I get the "margins are outside ..." message in front.

Sorry - I'm stumped. Why not try a few other OS and machine combinations?

--
Mark Alexander Bertenshaw
Programmer/Analyst
PrimeResponse
Brentford
UK

"TC" <no@email.please> wrote in message
news:01c02aa2$91f38ca0$45fb98cb@pentium...
> Mark
>
> Thanks for your reply.
>
> I'm using Access 97 on Windows 95 version 4.00.950b (the OEM version).
>
> I try to test all my code on w95, 98, NT & 2000, but I'm still stuck
> getting this to work on w95!
>
> The only fact that I omitted (because I hoped it was irrelevant), is this.
> I don't have a printer on the PC that I'm testing this from. When the code
> executes the .PrintOut method, a dialog box comes up from Microsoft FAX
> (which I assume is the default print driver) saying that there is an
error.
> This dialog box IS forced to the front. The .PrintOut call does NOT return
> yet. When I OK that dialog box, the .PrintOut call returns, and the rest
of
> the problem occurs as described - in particular, the "Margins are
> outside..." dialog box is displayed "behind the scenes" (not forced to the
> front).
>
> Does this give you any extra clues?
>
> Are you sure your document is producing the required error? ("Margins are
> outside... etc.").
>
> Thanks again,
> TC
>
>
>
> Mark Alexander Bertenshaw <mark.bertenshaw@virgin.net> wrote in article
> <39d54d54@news.devx.com>...
> > TC -
> >
> > I have pasted this code into both VB 5 and Access 97, and it seems to
> work!!
> >
> > BTW I am using Windows 98. What are you using?
> >
> > --
> > Mark Alexander Bertenshaw
> > Programmer/Analyst
> > PrimeResponse
> > Brentford
> > UK
> >
> > "TC" <no@email.please> wrote in message
> > news:01c02a2e$bf913280$15fb98cb@pentium...
> > > Hi Folks
> > >
> > > I've been trying to solve the following problem on & off for about 6
> > weeks.
> > >
> > > If anyone can shed any light on it, I'd be very appreciative!
> > >
> > > I'm trying to print a document from MS Access 97 VBA using automation
> to
> > MS
> > > Word 97. I'm assuming the problem is Windows/VBA related, not Access
> > > related, and would therefore happen in VB also. Hence my desperate
> resort
> > > to this newsgroup!
> > >
> > > Here's the VBA I'm using:
> > >
> > > Public Sub doit()
> > > Dim oWord As Object
> > > Set oWord = CreateObject("word.application")
> > > oWord.Documents.Open "C:\TEST.doc"
> > > 'MsgBox "BLAH" ' [A]
> > > 'oWord.Visible = True ' [B]
> > > oWord.PrintOut Background:=True
> > > ' [C]
> > > MsgBox "OK"
> > > oWord.Quit 0 ' 0=discard changes.
> > > Set oWord = Nothing
> > > End Sub
> > >
> > > The document in question has a margin set outside the printable area
of
> > the
> > > page. This can be achieved by opening any document, going to page
> preview
> > > mode, dragging the top margin right up close to the top of the page,
> then
> > > saving the document & exitting Word. Printing the document (in the
> normal
> > > way from Word) should display a dialog box: "The margins of section 1
> are
> > > set outside the printable area of the page. Do you want to continue?
> > > [Yes]/[No]".
> > >
> > > When I run this sub from the Access IDE, the dialog box noted above is
> > > displayed BELOW the Access IDE - not ABOVE it - so it is not visible -
> so
> > > the user does not know it's there, and can not answer it. The sub then
> > > appears to hang. Any reference in the sub to any method or property of
> the
> > > oWord object, will hang (eg. oWord.Quit). Even trying to set
> > > oWord.Visible=True will hang.
> > >
> > > I concluded that I needed, on return from the .PrintOut call, to
detect
> > > whether Word had displayed a dialog box, and if so, bring it to the
> > > foreground (using API calls, not oWord methods or properties) so the
> user
> > > could answer it.
> > >
> > > I confirmed that the oWord.PrintOut statement returns immediately to
> point
> > > [C] before the dialog box has been displayed. I wrote some code to
wait
> > for
> > > a second or two at that point, then look for the dialog box with
> > > FindWindow("#32770","Microsoft Word"). This code successfully found (&
> > > returned the handle to) the relevant dialog box.
> > >
> > > However, I can not then (for the life of me) swap to the dialog box in
> > such
> > > a way that everything continues ok when the user answers it! I've
> tried:
> > > BringWindowToTop on every conceivable window handle including the Word
> > main
> > > window handle, the dialog box window handle, the dialog box OK button
> > > window handle, and so on;
> > > SetForeGroundWindow ditto;
> > > Access VBA AppActivate on the Word window caption, and
> > > Many & varied combinations of the above!
> > >
> > > Whatever I do, the following happens:
> > > My code makes the dialog box appear (with or without the Word main
> > window);
> > > The dialog box lets me click Yes or No;
> > > Someone (presumably Word or Windows) repaints the screen area that the
> > > dialog box overlayed, but then:
> > > MS Word hangs! Its window is still displayed, but it doesn't respond
to
> > any
> > > keystrokes, mouse clicks, dragging actions or whatever.
> > > Then the Access IDE hangs: sometimes showing a popup message that MS
> Word
> > > is not responding, and sometimes not.
> > >
> > > And here's the rub! :-
> > >
> > > If I include statement [A] or [B], it all works fine! (ie. nothing
> hangs).
> > > If I don't include them, it hangs as described above!
> > >
> > > I've checked GetActiveWindow() at various points (with and without
> > > statements [A] and [B]) but this always points to the Access IDE
> window.
> > >
> > > This is driving me A*B*S*O*L*U*T*E*L*Y M*E*N*T*A*L.
> > >
> > > Can anyone help me on this please.
> > >
> > > Thanks,
> > > TC
> > >
> >
> >
> >

[TC]

Mark

Thanks for your reply. I'll certainly try it on other OSs, but I'm
absolutely determined to get it going on win95 as well!

In fact, I think I've found the problem.

I was browsing through the MS Automation Help file (auto2000.chm) when I
came across an example of using SetForegroundWindow to make Access visible
when it is run via automation, eg. from Word. That's similar to what I'm
doing, namely, using SetForegroundWindow to make Word visible when it is
run via automation from Access. However, their example had a ShowWindow
after SetForegroundWindow. I've done some tests, and found that adding a
ShowWindow(hWord,SW_NORMAL) after the SetForegroundWindow makes the problem
go away - even though the SetForegroundWindow call does restore Word, and
make it visible!

Since I've been trying to fix this problem for >6 weeks, I think I'll spend
a few days more to understand exactly what's hapenning, then maybe post a
summary, for anyone who might still be interested.

Thanks again for your help.

TC



Mark Alexander Bertenshaw <mark.bertenshaw@virgin.net> wrote in article
<39d5f30f@news.devx.com>...
> Mark -
>
> Well, I am in the same position - I didn't have a printer connected
either.
> And I am positive that I get the "margins are outside ..." message in
front.
>
> Sorry - I'm stumped. Why not try a few other OS and machine
combinations?
>
> --
> Mark Alexander Bertenshaw
> Programmer/Analyst
> PrimeResponse
> Brentford
> UK
>
> "TC" <no@email.please> wrote in message
> news:01c02aa2$91f38ca0$45fb98cb@pentium...
> > Mark
> >
> > Thanks for your reply.
> >
> > I'm using Access 97 on Windows 95 version 4.00.950b (the OEM version).
> >
> > I try to test all my code on w95, 98, NT & 2000, but I'm still stuck
> > getting this to work on w95!
> >
> > The only fact that I omitted (because I hoped it was irrelevant), is
this.
> > I don't have a printer on the PC that I'm testing this from. When the
code
> > executes the .PrintOut method, a dialog box comes up from Microsoft FAX
> > (which I assume is the default print driver) saying that there is an
> error.
> > This dialog box IS forced to the front. The .PrintOut call does NOT
return
> > yet. When I OK that dialog box, the .PrintOut call returns, and the
rest
> of
> > the problem occurs as described - in particular, the "Margins are
> > outside..." dialog box is displayed "behind the scenes" (not forced to
the
> > front).
> >
> > Does this give you any extra clues?
> >
> > Are you sure your document is producing the required error? ("Margins
are
> > outside... etc.").
> >
> > Thanks again,
> > TC
> >
> >
> >
> > Mark Alexander Bertenshaw <mark.bertenshaw@virgin.net> wrote in article
> > <39d54d54@news.devx.com>...
> > > TC -
> > >
> > > I have pasted this code into both VB 5 and Access 97, and it seems to
> > work!!
> > >
> > > BTW I am using Windows 98. What are you using?
> > >
> > > --
> > > Mark Alexander Bertenshaw
> > > Programmer/Analyst
> > > PrimeResponse
> > > Brentford
> > > UK
> > >
> > > "TC" <no@email.please> wrote in message
> > > news:01c02a2e$bf913280$15fb98cb@pentium...
> > > > Hi Folks
> > > >
> > > > I've been trying to solve the following problem on & off for about
6
> > > weeks.
> > > >
> > > > If anyone can shed any light on it, I'd be very appreciative!
> > > >
> > > > I'm trying to print a document from MS Access 97 VBA using
automation
> > to
> > > MS
> > > > Word 97. I'm assuming the problem is Windows/VBA related, not
Access
> > > > related, and would therefore happen in VB also. Hence my desperate
> > resort
> > > > to this newsgroup!
> > > >
> > > > Here's the VBA I'm using:
> > > >
> > > > Public Sub doit()
> > > > Dim oWord As Object
> > > > Set oWord = CreateObject("word.application")
> > > > oWord.Documents.Open "C:\TEST.doc"
> > > > 'MsgBox "BLAH" ' [A]
> > > > 'oWord.Visible = True ' [B]
> > > > oWord.PrintOut Background:=True
> > > > ' [C]
> > > > MsgBox "OK"
> > > > oWord.Quit 0 ' 0=discard changes.
> > > > Set oWord = Nothing
> > > > End Sub
> > > >
> > > > The document in question has a margin set outside the printable
area
> of
> > > the
> > > > page. This can be achieved by opening any document, going to page
> > preview
> > > > mode, dragging the top margin right up close to the top of the
page,
> > then
> > > > saving the document & exitting Word. Printing the document (in the
> > normal
> > > > way from Word) should display a dialog box: "The margins of section
1
> > are
> > > > set outside the printable area of the page. Do you want to
continue?
> > > > [Yes]/[No]".
> > > >
> > > > When I run this sub from the Access IDE, the dialog box noted above
is
> > > > displayed BELOW the Access IDE - not ABOVE it - so it is not
visible -
> > so
> > > > the user does not know it's there, and can not answer it. The sub
then
> > > > appears to hang. Any reference in the sub to any method or property
of
> > the
> > > > oWord object, will hang (eg. oWord.Quit). Even trying to set
> > > > oWord.Visible=True will hang.
> > > >
> > > > I concluded that I needed, on return from the .PrintOut call, to
> detect
> > > > whether Word had displayed a dialog box, and if so, bring it to the
> > > > foreground (using API calls, not oWord methods or properties) so
the
> > user
> > > > could answer it.
> > > >
> > > > I confirmed that the oWord.PrintOut statement returns immediately
to
> > point
> > > > [C] before the dialog box has been displayed. I wrote some code to
> wait
> > > for
> > > > a second or two at that point, then look for the dialog box with
> > > > FindWindow("#32770","Microsoft Word"). This code successfully found
(&
> > > > returned the handle to) the relevant dialog box.
> > > >
> > > > However, I can not then (for the life of me) swap to the dialog box
in
> > > such
> > > > a way that everything continues ok when the user answers it! I've
> > tried:
> > > > BringWindowToTop on every conceivable window handle including the
Word
> > > main
> > > > window handle, the dialog box window handle, the dialog box OK
button
> > > > window handle, and so on;
> > > > SetForeGroundWindow ditto;
> > > > Access VBA AppActivate on the Word window caption, and
> > > > Many & varied combinations of the above!
> > > >
> > > > Whatever I do, the following happens:
> > > > My code makes the dialog box appear (with or without the Word main
> > > window);
> > > > The dialog box lets me click Yes or No;
> > > > Someone (presumably Word or Windows) repaints the screen area that
the
> > > > dialog box overlayed, but then:
> > > > MS Word hangs! Its window is still displayed, but it doesn't
respond
> to
> > > any
> > > > keystrokes, mouse clicks, dragging actions or whatever.
> > > > Then the Access IDE hangs: sometimes showing a popup message that
MS
> > Word
> > > > is not responding, and sometimes not.
> > > >
> > > > And here's the rub! :-
> > > >
> > > > If I include statement [A] or [B], it all works fine! (ie. nothing
> > hangs).
> > > > If I don't include them, it hangs as described above!
> > > >
> > > > I've checked GetActiveWindow() at various points (with and without
> > > > statements [A] and [B]) but this always points to the Access IDE
> > window.
> > > >
> > > > This is driving me A*B*S*O*L*U*T*E*L*Y M*E*N*T*A*L.
> > > >
> > > > Can anyone help me on this please.
> > > >
> > > > Thanks,
> > > > TC
> > > >
> > >
> > >
> > >
>
>
>

[TC]

Mark

Thanks for your reply. I'll certainly try it on other OSs, but I'm
absolutely determined to get it going on win95 as well!

In fact, I think I've found the problem.

I was browsing through the MS Automation Help file (auto2000.chm) when I
came across an example of using SetForegroundWindow to make Access visible
when it is run via automation, eg. from Word. That's similar to what I'm
doing, namely, using SetForegroundWindow to make Word visible when it is
run via automation from Access. However, their example had a ShowWindow
after SetForegroundWindow. I've done some tests, and found that adding a
ShowWindow(hWord,SW_NORMAL) after the SetForegroundWindow makes the problem
go away - even though the SetForegroundWindow call does restore Word, and
make it visible!

Since I've been trying to fix this problem for >6 weeks, I think I'll spend
a few days more to understand exactly what's hapenning, then maybe post a
summary, for anyone who might still be interested.

Thanks again for your help.

TC



Mark Alexander Bertenshaw <mark.bertenshaw@virgin.net> wrote in article
<39d5f30f@news.devx.com>...
> Mark -
>
> Well, I am in the same position - I didn't have a printer connected
either.
> And I am positive that I get the "margins are outside ..." message in
front.
>
> Sorry - I'm stumped. Why not try a few other OS and machine
combinations?
>
> --
> Mark Alexander Bertenshaw
> Programmer/Analyst
> PrimeResponse
> Brentford
> UK
>
> "TC" <no@email.please> wrote in message
> news:01c02aa2$91f38ca0$45fb98cb@pentium...
> > Mark
> >
> > Thanks for your reply.
> >
> > I'm using Access 97 on Windows 95 version 4.00.950b (the OEM version).
> >
> > I try to test all my code on w95, 98, NT & 2000, but I'm still stuck
> > getting this to work on w95!
> >
> > The only fact that I omitted (because I hoped it was irrelevant), is
this.
> > I don't have a printer on the PC that I'm testing this from. When the
code
> > executes the .PrintOut method, a dialog box comes up from Microsoft FAX
> > (which I assume is the default print driver) saying that there is an
> error.
> > This dialog box IS forced to the front. The .PrintOut call does NOT
return
> > yet. When I OK that dialog box, the .PrintOut call returns, and the
rest
> of
> > the problem occurs as described - in particular, the "Margins are
> > outside..." dialog box is displayed "behind the scenes" (not forced to
the
> > front).
> >
> > Does this give you any extra clues?
> >
> > Are you sure your document is producing the required error? ("Margins
are
> > outside... etc.").
> >
> > Thanks again,
> > TC
> >
> >
> >
> > Mark Alexander Bertenshaw <mark.bertenshaw@virgin.net> wrote in article
> > <39d54d54@news.devx.com>...
> > > TC -
> > >
> > > I have pasted this code into both VB 5 and Access 97, and it seems to
> > work!!
> > >
> > > BTW I am using Windows 98. What are you using?
> > >
> > > --
> > > Mark Alexander Bertenshaw
> > > Programmer/Analyst
> > > PrimeResponse
> > > Brentford
> > > UK
> > >
> > > "TC" <no@email.please> wrote in message
> > > news:01c02a2e$bf913280$15fb98cb@pentium...
> > > > Hi Folks
> > > >
> > > > I've been trying to solve the following problem on & off for about
6
> > > weeks.
> > > >
> > > > If anyone can shed any light on it, I'd be very appreciative!
> > > >
> > > > I'm trying to print a document from MS Access 97 VBA using
automation
> > to
> > > MS
> > > > Word 97. I'm assuming the problem is Windows/VBA related, not
Access
> > > > related, and would therefore happen in VB also. Hence my desperate
> > resort
> > > > to this newsgroup!
> > > >
> > > > Here's the VBA I'm using:
> > > >
> > > > Public Sub doit()
> > > > Dim oWord As Object
> > > > Set oWord = CreateObject("word.application")
> > > > oWord.Documents.Open "C:\TEST.doc"
> > > > 'MsgBox "BLAH" ' [A]
> > > > 'oWord.Visible = True ' [B]
> > > > oWord.PrintOut Background:=True
> > > > ' [C]
> > > > MsgBox "OK"
> > > > oWord.Quit 0 ' 0=discard changes.
> > > > Set oWord = Nothing
> > > > End Sub
> > > >
> > > > The document in question has a margin set outside the printable
area
> of
> > > the
> > > > page. This can be achieved by opening any document, going to page
> > preview
> > > > mode, dragging the top margin right up close to the top of the
page,
> > then
> > > > saving the document & exitting Word. Printing the document (in the
> > normal
> > > > way from Word) should display a dialog box: "The margins of section
1
> > are
> > > > set outside the printable area of the page. Do you want to
continue?
> > > > [Yes]/[No]".
> > > >
> > > > When I run this sub from the Access IDE, the dialog box noted above
is
> > > > displayed BELOW the Access IDE - not ABOVE it - so it is not
visible -
> > so
> > > > the user does not know it's there, and can not answer it. The sub
then
> > > > appears to hang. Any reference in the sub to any method or property
of
> > the
> > > > oWord object, will hang (eg. oWord.Quit). Even trying to set
> > > > oWord.Visible=True will hang.
> > > >
> > > > I concluded that I needed, on return from the .PrintOut call, to
> detect
> > > > whether Word had displayed a dialog box, and if so, bring it to the
> > > > foreground (using API calls, not oWord methods or properties) so
the
> > user
> > > > could answer it.
> > > >
> > > > I confirmed that the oWord.PrintOut statement returns immediately
to
> > point
> > > > [C] before the dialog box has been displayed. I wrote some code to
> wait
> > > for
> > > > a second or two at that point, then look for the dialog box with
> > > > FindWindow("#32770","Microsoft Word"). This code successfully found
(&
> > > > returned the handle to) the relevant dialog box.
> > > >
> > > > However, I can not then (for the life of me) swap to the dialog box
in
> > > such
> > > > a way that everything continues ok when the user answers it! I've
> > tried:
> > > > BringWindowToTop on every conceivable window handle including the
Word
> > > main
> > > > window handle, the dialog box window handle, the dialog box OK
button
> > > > window handle, and so on;
> > > > SetForeGroundWindow ditto;
> > > > Access VBA AppActivate on the Word window caption, and
> > > > Many & varied combinations of the above!
> > > >
> > > > Whatever I do, the following happens:
> > > > My code makes the dialog box appear (with or without the Word main
> > > window);
> > > > The dialog box lets me click Yes or No;
> > > > Someone (presumably Word or Windows) repaints the screen area that
the
> > > > dialog box overlayed, but then:
> > > > MS Word hangs! Its window is still displayed, but it doesn't
respond
> to
> > > any
> > > > keystrokes, mouse clicks, dragging actions or whatever.
> > > > Then the Access IDE hangs: sometimes showing a popup message that
MS
> > Word
> > > > is not responding, and sometimes not.
> > > >
> > > > And here's the rub! :-
> > > >
> > > > If I include statement [A] or [B], it all works fine! (ie. nothing
> > hangs).
> > > > If I don't include them, it hangs as described above!
> > > >
> > > > I've checked GetActiveWindow() at various points (with and without
> > > > statements [A] and [B]) but this always points to the Access IDE
> > window.
> > > >
> > > > This is driving me A*B*S*O*L*U*T*E*L*Y M*E*N*T*A*L.
> > > >
> > > > Can anyone help me on this please.
> > > >
> > > > Thanks,
> > > > TC
> > > >
> > >
> > >
> > >
>
>
>

[Andrew Parsons]

We've actually been trying to solve a similar problem for months.

It doesn't seem to be OS related, as it will be fine sometimes but most of
the time, the dialog box appears BEHIND the other form.

For us, it is straight VB6 and happens at application load time. The splash
screen is shown, then if we get an automation error or something else before
the main form is shown, the message box appears - behind the splash screen.

I'm sorry that I can't help you TC - I just wanted to let you know that
you're not going crazy.

One tip though. I work in a commercial off-the-shelf package company. We do
our development on Win98 and get it working there. We worry about Win95
later. There are too many problems that are peculiar to Win95 that can get
you off the beaten track of getting software working.

Cheers
Andrew

"TC" <no@email.please> wrote in message
news:01c02bd7$cd35ec00$65fa98cb@pentium...
> Mark
>
> Thanks for your reply. I'll certainly try it on other OSs, but I'm
> absolutely determined to get it going on win95 as well!
>
> In fact, I think I've found the problem.
>
> I was browsing through the MS Automation Help file (auto2000.chm) when I
> came across an example of using SetForegroundWindow to make Access visible
> when it is run via automation, eg. from Word. That's similar to what I'm
> doing, namely, using SetForegroundWindow to make Word visible when it is
> run via automation from Access. However, their example had a ShowWindow
> after SetForegroundWindow. I've done some tests, and found that adding a
> ShowWindow(hWord,SW_NORMAL) after the SetForegroundWindow makes the
problem
> go away - even though the SetForegroundWindow call does restore Word, and
> make it visible!
>
> Since I've been trying to fix this problem for >6 weeks, I think I'll
spend
> a few days more to understand exactly what's hapenning, then maybe post a
> summary, for anyone who might still be interested.
>
> Thanks again for your help.
>
> TC
>
>
>
> Mark Alexander Bertenshaw <mark.bertenshaw@virgin.net> wrote in article
> <39d5f30f@news.devx.com>...
> > Mark -
> >
> > Well, I am in the same position - I didn't have a printer connected
> either.
> > And I am positive that I get the "margins are outside ..." message in
> front.
> >
> > Sorry - I'm stumped. Why not try a few other OS and machine
> combinations?
> >
> > --
> > Mark Alexander Bertenshaw
> > Programmer/Analyst
> > PrimeResponse
> > Brentford
> > UK
> >
> > "TC" <no@email.please> wrote in message
> > news:01c02aa2$91f38ca0$45fb98cb@pentium...
> > > Mark
> > >
> > > Thanks for your reply.
> > >
> > > I'm using Access 97 on Windows 95 version 4.00.950b (the OEM version).
> > >
> > > I try to test all my code on w95, 98, NT & 2000, but I'm still stuck
> > > getting this to work on w95!
> > >
> > > The only fact that I omitted (because I hoped it was irrelevant), is
> this.
> > > I don't have a printer on the PC that I'm testing this from. When the
> code
> > > executes the .PrintOut method, a dialog box comes up from Microsoft
FAX
> > > (which I assume is the default print driver) saying that there is an
> > error.
> > > This dialog box IS forced to the front. The .PrintOut call does NOT
> return
> > > yet. When I OK that dialog box, the .PrintOut call returns, and the
> rest
> > of
> > > the problem occurs as described - in particular, the "Margins are
> > > outside..." dialog box is displayed "behind the scenes" (not forced to
> the
> > > front).
> > >
> > > Does this give you any extra clues?
> > >
> > > Are you sure your document is producing the required error? ("Margins
> are
> > > outside... etc.").
> > >
> > > Thanks again,
> > > TC
> > >
> > >
> > >
> > > Mark Alexander Bertenshaw <mark.bertenshaw@virgin.net> wrote in
article
> > > <39d54d54@news.devx.com>...
> > > > TC -
> > > >
> > > > I have pasted this code into both VB 5 and Access 97, and it seems
to
> > > work!!
> > > >
> > > > BTW I am using Windows 98. What are you using?
> > > >
> > > > --
> > > > Mark Alexander Bertenshaw
> > > > Programmer/Analyst
> > > > PrimeResponse
> > > > Brentford
> > > > UK
> > > >
> > > > "TC" <no@email.please> wrote in message
> > > > news:01c02a2e$bf913280$15fb98cb@pentium...
> > > > > Hi Folks
> > > > >
> > > > > I've been trying to solve the following problem on & off for about
> 6
> > > > weeks.
> > > > >
> > > > > If anyone can shed any light on it, I'd be very appreciative!
> > > > >
> > > > > I'm trying to print a document from MS Access 97 VBA using
> automation
> > > to
> > > > MS
> > > > > Word 97. I'm assuming the problem is Windows/VBA related, not
> Access
> > > > > related, and would therefore happen in VB also. Hence my desperate
> > > resort
> > > > > to this newsgroup!
> > > > >
> > > > > Here's the VBA I'm using:
> > > > >
> > > > > Public Sub doit()
> > > > > Dim oWord As Object
> > > > > Set oWord = CreateObject("word.application")
> > > > > oWord.Documents.Open "C:\TEST.doc"
> > > > > 'MsgBox "BLAH" ' [A]
> > > > > 'oWord.Visible = True ' [B]
> > > > > oWord.PrintOut Background:=True
> > > > > ' [C]
> > > > > MsgBox "OK"
> > > > > oWord.Quit 0 ' 0=discard changes.
> > > > > Set oWord = Nothing
> > > > > End Sub
> > > > >
> > > > > The document in question has a margin set outside the printable
> area
> > of
> > > > the
> > > > > page. This can be achieved by opening any document, going to page
> > > preview
> > > > > mode, dragging the top margin right up close to the top of the
> page,
> > > then
> > > > > saving the document & exitting Word. Printing the document (in the
> > > normal
> > > > > way from Word) should display a dialog box: "The margins of
section
> 1
> > > are
> > > > > set outside the printable area of the page. Do you want to
> continue?
> > > > > [Yes]/[No]".
> > > > >
> > > > > When I run this sub from the Access IDE, the dialog box noted
above
> is
> > > > > displayed BELOW the Access IDE - not ABOVE it - so it is not
> visible -
> > > so
> > > > > the user does not know it's there, and can not answer it. The sub
> then
> > > > > appears to hang. Any reference in the sub to any method or
property
> of
> > > the
> > > > > oWord object, will hang (eg. oWord.Quit). Even trying to set
> > > > > oWord.Visible=True will hang.
> > > > >
> > > > > I concluded that I needed, on return from the .PrintOut call, to
> > detect
> > > > > whether Word had displayed a dialog box, and if so, bring it to
the
> > > > > foreground (using API calls, not oWord methods or properties) so
> the
> > > user
> > > > > could answer it.
> > > > >
> > > > > I confirmed that the oWord.PrintOut statement returns immediately
> to
> > > point
> > > > > [C] before the dialog box has been displayed. I wrote some code to
> > wait
> > > > for
> > > > > a second or two at that point, then look for the dialog box with
> > > > > FindWindow("#32770","Microsoft Word"). This code successfully
found
> (&
> > > > > returned the handle to) the relevant dialog box.
> > > > >
> > > > > However, I can not then (for the life of me) swap to the dialog
box
> in
> > > > such
> > > > > a way that everything continues ok when the user answers it! I've
> > > tried:
> > > > > BringWindowToTop on every conceivable window handle including the
> Word
> > > > main
> > > > > window handle, the dialog box window handle, the dialog box OK
> button
> > > > > window handle, and so on;
> > > > > SetForeGroundWindow ditto;
> > > > > Access VBA AppActivate on the Word window caption, and
> > > > > Many & varied combinations of the above!
> > > > >
> > > > > Whatever I do, the following happens:
> > > > > My code makes the dialog box appear (with or without the Word main
> > > > window);
> > > > > The dialog box lets me click Yes or No;
> > > > > Someone (presumably Word or Windows) repaints the screen area that
> the
> > > > > dialog box overlayed, but then:
> > > > > MS Word hangs! Its window is still displayed, but it doesn't
> respond
> > to
> > > > any
> > > > > keystrokes, mouse clicks, dragging actions or whatever.
> > > > > Then the Access IDE hangs: sometimes showing a popup message that
> MS
> > > Word
> > > > > is not responding, and sometimes not.
> > > > >
> > > > > And here's the rub! :-
> > > > >
> > > > > If I include statement [A] or [B], it all works fine! (ie. nothing
> > > hangs).
> > > > > If I don't include them, it hangs as described above!
> > > > >
> > > > > I've checked GetActiveWindow() at various points (with and without
> > > > > statements [A] and [B]) but this always points to the Access IDE
> > > window.
> > > > >
> > > > > This is driving me A*B*S*O*L*U*T*E*L*Y M*E*N*T*A*L.
> > > > >
> > > > > Can anyone help me on this please.
> > > > >
> > > > > Thanks,
> > > > > TC
> > > > >
> > > >
> > > >
> > > >
> >
> >
> >

[Andrew Parsons]

We've actually been trying to solve a similar problem for months.

It doesn't seem to be OS related, as it will be fine sometimes but most of
the time, the dialog box appears BEHIND the other form.

For us, it is straight VB6 and happens at application load time. The splash
screen is shown, then if we get an automation error or something else before
the main form is shown, the message box appears - behind the splash screen.

I'm sorry that I can't help you TC - I just wanted to let you know that
you're not going crazy.

One tip though. I work in a commercial off-the-shelf package company. We do
our development on Win98 and get it working there. We worry about Win95
later. There are too many problems that are peculiar to Win95 that can get
you off the beaten track of getting software working.

Cheers
Andrew

"TC" <no@email.please> wrote in message
news:01c02bd7$cd35ec00$65fa98cb@pentium...
> Mark
>
> Thanks for your reply. I'll certainly try it on other OSs, but I'm
> absolutely determined to get it going on win95 as well!
>
> In fact, I think I've found the problem.
>
> I was browsing through the MS Automation Help file (auto2000.chm) when I
> came across an example of using SetForegroundWindow to make Access visible
> when it is run via automation, eg. from Word. That's similar to what I'm
> doing, namely, using SetForegroundWindow to make Word visible when it is
> run via automation from Access. However, their example had a ShowWindow
> after SetForegroundWindow. I've done some tests, and found that adding a
> ShowWindow(hWord,SW_NORMAL) after the SetForegroundWindow makes the
problem
> go away - even though the SetForegroundWindow call does restore Word, and
> make it visible!
>
> Since I've been trying to fix this problem for >6 weeks, I think I'll
spend
> a few days more to understand exactly what's hapenning, then maybe post a
> summary, for anyone who might still be interested.
>
> Thanks again for your help.
>
> TC
>
>
>
> Mark Alexander Bertenshaw <mark.bertenshaw@virgin.net> wrote in article
> <39d5f30f@news.devx.com>...
> > Mark -
> >
> > Well, I am in the same position - I didn't have a printer connected
> either.
> > And I am positive that I get the "margins are outside ..." message in
> front.
> >
> > Sorry - I'm stumped. Why not try a few other OS and machine
> combinations?
> >
> > --
> > Mark Alexander Bertenshaw
> > Programmer/Analyst
> > PrimeResponse
> > Brentford
> > UK
> >
> > "TC" <no@email.please> wrote in message
> > news:01c02aa2$91f38ca0$45fb98cb@pentium...
> > > Mark
> > >
> > > Thanks for your reply.
> > >
> > > I'm using Access 97 on Windows 95 version 4.00.950b (the OEM version).
> > >
> > > I try to test all my code on w95, 98, NT & 2000, but I'm still stuck
> > > getting this to work on w95!
> > >
> > > The only fact that I omitted (because I hoped it was irrelevant), is
> this.
> > > I don't have a printer on the PC that I'm testing this from. When the
> code
> > > executes the .PrintOut method, a dialog box comes up from Microsoft
FAX
> > > (which I assume is the default print driver) saying that there is an
> > error.
> > > This dialog box IS forced to the front. The .PrintOut call does NOT
> return
> > > yet. When I OK that dialog box, the .PrintOut call returns, and the
> rest
> > of
> > > the problem occurs as described - in particular, the "Margins are
> > > outside..." dialog box is displayed "behind the scenes" (not forced to
> the
> > > front).
> > >
> > > Does this give you any extra clues?
> > >
> > > Are you sure your document is producing the required error? ("Margins
> are
> > > outside... etc.").
> > >
> > > Thanks again,
> > > TC
> > >
> > >
> > >
> > > Mark Alexander Bertenshaw <mark.bertenshaw@virgin.net> wrote in
article
> > > <39d54d54@news.devx.com>...
> > > > TC -
> > > >
> > > > I have pasted this code into both VB 5 and Access 97, and it seems
to
> > > work!!
> > > >
> > > > BTW I am using Windows 98. What are you using?
> > > >
> > > > --
> > > > Mark Alexander Bertenshaw
> > > > Programmer/Analyst
> > > > PrimeResponse
> > > > Brentford
> > > > UK
> > > >
> > > > "TC" <no@email.please> wrote in message
> > > > news:01c02a2e$bf913280$15fb98cb@pentium...
> > > > > Hi Folks
> > > > >
> > > > > I've been trying to solve the following problem on & off for about
> 6
> > > > weeks.
> > > > >
> > > > > If anyone can shed any light on it, I'd be very appreciative!
> > > > >
> > > > > I'm trying to print a document from MS Access 97 VBA using
> automation
> > > to
> > > > MS
> > > > > Word 97. I'm assuming the problem is Windows/VBA related, not
> Access
> > > > > related, and would therefore happen in VB also. Hence my desperate
> > > resort
> > > > > to this newsgroup!
> > > > >
> > > > > Here's the VBA I'm using:
> > > > >
> > > > > Public Sub doit()
> > > > > Dim oWord As Object
> > > > > Set oWord = CreateObject("word.application")
> > > > > oWord.Documents.Open "C:\TEST.doc"
> > > > > 'MsgBox "BLAH" ' [A]
> > > > > 'oWord.Visible = True ' [B]
> > > > > oWord.PrintOut Background:=True
> > > > > ' [C]
> > > > > MsgBox "OK"
> > > > > oWord.Quit 0 ' 0=discard changes.
> > > > > Set oWord = Nothing
> > > > > End Sub
> > > > >
> > > > > The document in question has a margin set outside the printable
> area
> > of
> > > > the
> > > > > page. This can be achieved by opening any document, going to page
> > > preview
> > > > > mode, dragging the top margin right up close to the top of the
> page,
> > > then
> > > > > saving the document & exitting Word. Printing the document (in the
> > > normal
> > > > > way from Word) should display a dialog box: "The margins of
section
> 1
> > > are
> > > > > set outside the printable area of the page. Do you want to
> continue?
> > > > > [Yes]/[No]".
> > > > >
> > > > > When I run this sub from the Access IDE, the dialog box noted
above
> is
> > > > > displayed BELOW the Access IDE - not ABOVE it - so it is not
> visible -
> > > so
> > > > > the user does not know it's there, and can not answer it. The sub
> then
> > > > > appears to hang. Any reference in the sub to any method or
property
> of
> > > the
> > > > > oWord object, will hang (eg. oWord.Quit). Even trying to set
> > > > > oWord.Visible=True will hang.
> > > > >
> > > > > I concluded that I needed, on return from the .PrintOut call, to
> > detect
> > > > > whether Word had displayed a dialog box, and if so, bring it to
the
> > > > > foreground (using API calls, not oWord methods or properties) so
> the
> > > user
> > > > > could answer it.
> > > > >
> > > > > I confirmed that the oWord.PrintOut statement returns immediately
> to
> > > point
> > > > > [C] before the dialog box has been displayed. I wrote some code to
> > wait
> > > > for
> > > > > a second or two at that point, then look for the dialog box with
> > > > > FindWindow("#32770","Microsoft Word"). This code successfully
found
> (&
> > > > > returned the handle to) the relevant dialog box.
> > > > >
> > > > > However, I can not then (for the life of me) swap to the dialog
box
> in
> > > > such
> > > > > a way that everything continues ok when the user answers it! I've
> > > tried:
> > > > > BringWindowToTop on every conceivable window handle including the
> Word
> > > > main
> > > > > window handle, the dialog box window handle, the dialog box OK
> button
> > > > > window handle, and so on;
> > > > > SetForeGroundWindow ditto;
> > > > > Access VBA AppActivate on the Word window caption, and
> > > > > Many & varied combinations of the above!
> > > > >
> > > > > Whatever I do, the following happens:
> > > > > My code makes the dialog box appear (with or without the Word main
> > > > window);
> > > > > The dialog box lets me click Yes or No;
> > > > > Someone (presumably Word or Windows) repaints the screen area that
> the
> > > > > dialog box overlayed, but then:
> > > > > MS Word hangs! Its window is still displayed, but it doesn't
> respond
> > to
> > > > any
> > > > > keystrokes, mouse clicks, dragging actions or whatever.
> > > > > Then the Access IDE hangs: sometimes showing a popup message that
> MS
> > > Word
> > > > > is not responding, and sometimes not.
> > > > >
> > > > > And here's the rub! :-
> > > > >
> > > > > If I include statement [A] or [B], it all works fine! (ie. nothing
> > > hangs).
> > > > > If I don't include them, it hangs as described above!
> > > > >
> > > > > I've checked GetActiveWindow() at various points (with and without
> > > > > statements [A] and [B]) but this always points to the Access IDE
> > > window.
> > > > >
> > > > > This is driving me A*B*S*O*L*U*T*E*L*Y M*E*N*T*A*L.
> > > > >
> > > > > Can anyone help me on this please.
> > > > >
> > > > > Thanks,
> > > > > TC
> > > > >
> > > >
> > > >
> > > >
> >
> >
> >

[TC]

Andrew

Thanks - I'm most interested to hear that someone else has the same problem
- particularly on other-than win95. (I truly did wonder if I was going
crazy!)

I'm now getting inconsistent behaviour with my ShowWindow fix! Sometimes it
works & sometimes it doesn't - so clearly I don't have the whole story yet.

I'm determined to get to the bottom of this but it may take some time more.
When I do, I'll repost to this thread and/or email you. Perhaps you could
then try my (amended) fix on one of your misbehaving applications. Perhaps
you could "freeze dry" one, in anticipation?

Cheers,
TC


Andrew Parsons <andrewsNOSPAMmailers@optushome.com.au> wrote in article
<39da350c$1@news.devx.com>...
> We've actually been trying to solve a similar problem for months.
>
> It doesn't seem to be OS related, as it will be fine sometimes but most
of
> the time, the dialog box appears BEHIND the other form.
>
> For us, it is straight VB6 and happens at application load time. The
splash
> screen is shown, then if we get an automation error or something else
before
> the main form is shown, the message box appears - behind the splash
screen.
>
> I'm sorry that I can't help you TC - I just wanted to let you know that
> you're not going crazy.
>
> One tip though. I work in a commercial off-the-shelf package company. We
do
> our development on Win98 and get it working there. We worry about Win95
> later. There are too many problems that are peculiar to Win95 that can
get
> you off the beaten track of getting software working.
>
> Cheers
> Andrew

[TC]

Andrew

Thanks - I'm most interested to hear that someone else has the same problem
- particularly on other-than win95. (I truly did wonder if I was going
crazy!)

I'm now getting inconsistent behaviour with my ShowWindow fix! Sometimes it
works & sometimes it doesn't - so clearly I don't have the whole story yet.

I'm determined to get to the bottom of this but it may take some time more.
When I do, I'll repost to this thread and/or email you. Perhaps you could
then try my (amended) fix on one of your misbehaving applications. Perhaps
you could "freeze dry" one, in anticipation?

Cheers,
TC


Andrew Parsons <andrewsNOSPAMmailers@optushome.com.au> wrote in article
<39da350c$1@news.devx.com>...
> We've actually been trying to solve a similar problem for months.
>
> It doesn't seem to be OS related, as it will be fine sometimes but most
of
> the time, the dialog box appears BEHIND the other form.
>
> For us, it is straight VB6 and happens at application load time. The
splash
> screen is shown, then if we get an automation error or something else
before
> the main form is shown, the message box appears - behind the splash
screen.
>
> I'm sorry that I can't help you TC - I just wanted to let you know that
> you're not going crazy.
>
> One tip though. I work in a commercial off-the-shelf package company. We
do
> our development on Win98 and get it working there. We worry about Win95
> later. There are too many problems that are peculiar to Win95 that can
get
> you off the beaten track of getting software working.
>
> Cheers
> Andrew