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.

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

09-29-2000, 09:41 PM

Mark Alexander Bertenshaw

Re: HELP!! uncovering hidden dialog box

TC -

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

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

09-30-2000, 01:42 AM

TC

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

09-30-2000, 01:42 AM

TC

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

09-30-2000, 10:14 AM

Mark Alexander Bertenshaw

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?

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

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.

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.

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

10-04-2000, 03:42 AM

TC

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