HELP!! uncovering hidden dialog box


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Results 1 to 15 of 15

Thread: HELP!! uncovering hidden dialog box

  1. #1
    TC Guest

    HELP!! uncovering hidden dialog box

    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


  2. #2
    TC Guest

    Re: HELP!! uncovering hidden dialog box


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



    I mean GetForeGroundWindow().

    TC

  3. #3
    TC Guest

    Re: HELP!! uncovering hidden dialog box


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



    I mean GetForeGroundWindow().

    TC

  4. #4
    Mark Alexander Bertenshaw Guest

    Re: HELP!! uncovering hidden dialog box

    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
    >




  5. #5
    Mark Alexander Bertenshaw Guest

    Re: HELP!! uncovering hidden dialog box

    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
    >




  6. #6
    TC Guest

    Re: HELP!! uncovering hidden dialog box

    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
    > >

    >
    >
    >


  7. #7
    TC Guest

    Re: HELP!! uncovering hidden dialog box

    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
    > >

    >
    >
    >


  8. #8
    Mark Alexander Bertenshaw Guest

    Re: HELP!! uncovering hidden dialog box

    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
    > > >

    > >
    > >
    > >




  9. #9
    Mark Alexander Bertenshaw Guest

    Re: HELP!! uncovering hidden dialog box

    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
    > > >

    > >
    > >
    > >




  10. #10
    TC Guest

    Re: HELP!! uncovering hidden dialog box

    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
    > > > >
    > > >
    > > >
    > > >

    >
    >
    >


  11. #11
    TC Guest

    Re: HELP!! uncovering hidden dialog box

    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
    > > > >
    > > >
    > > >
    > > >

    >
    >
    >


  12. #12
    Andrew Parsons Guest

    Re: HELP!! uncovering hidden dialog box

    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
    > > > > >
    > > > >
    > > > >
    > > > >

    > >
    > >
    > >




  13. #13
    Andrew Parsons Guest

    Re: HELP!! uncovering hidden dialog box

    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
    > > > > >
    > > > >
    > > > >
    > > > >

    > >
    > >
    > >




  14. #14
    TC Guest

    Re: HELP!! uncovering hidden dialog box


    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


  15. #15
    TC Guest

    Re: HELP!! uncovering hidden dialog box


    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


Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
HTML5 Development Center
 
 
FAQ
Latest Articles
Java
.NET
XML
Database
Enterprise
Questions? Contact us.
C++
Web Development
Wireless
Latest Tips
Open Source


   Development Centers

   -- Android Development Center
   -- Cloud Development Project Center
   -- HTML5 Development Center
   -- Windows Mobile Development Center