I'm still using Office 2000 myself, but some of my clients have Office 2003.
I've recently added a piece of code to create an instance of Word, open a
document, fill in the blanks and become visible so the document can be
printed and/or modified.

This all takes place within one form, in which the Word.Application and
Word.Document objects are both private form-level variables. Just to be on
the safe side I included this piece of code in the Form_Close() event
procedure:

On Error Resume Next
doc.Close wdDoNotSaveChanges
app.Quit
Set doc = Nothing
Set app = Nothing

This all works fine in Access 2000 - if the objects are no longer set the
error trapping deals with it silently.

However, in Access 2003 it behaves exactly as if the 'On Error Resume Next'
were not there. In fact it seems to be the beyond reach of any kind of
error trapping code whatsoever!

Can anyone tell me whether this is a bug or a feature - and whichever it is,
how do I deal with it?

Thanks.

Captain Nemo wrote in message
<F34ag.69693$wl.62313@text.news.blueyonder.co.uk > :[color=blue]
> I'm still using Office 2000 myself, but some of my clients have
> Office 2003. I've recently added a piece of code to create an
> instance of Word, open a document, fill in the blanks and become
> visible so the document can be printed and/or modified.
>
> This all takes place within one form, in which the Word.Application
> and Word.Document objects are both private form-level variables.
> Just to be on the safe side I included this piece of code in the
> Form_Close() event procedure:
>
> On Error Resume Next
> doc.Close wdDoNotSaveChanges
> app.Quit
> Set doc = Nothing
> Set app = Nothing
>
> This all works fine in Access 2000 - if the objects are no longer set
> the error trapping deals with it silently.
>
> However, in Access 2003 it behaves exactly as if the 'On Error Resume
> Next' were not there. In fact it seems to be the beyond reach of any
> kind of error trapping code whatsoever!
>
> Can anyone tell me whether this is a bug or a feature - and whichever
> it is, how do I deal with it?
>
> Thanks.[/color]

My first guess, would be the setting for error trapping. In VBE - Tools
| Options - General Tab - make sure it's set to Break on Unhandled
Errors.

--
Roy-Vidar

"RoyVidar" <roy_vidarNOSPAM@yahoo.no> wrote in message
news:mn.7ce97d65315e8169.33955@yahoo.no...
[color=blue]
> My first guess, would be the setting for error trapping. In VBE - Tools
> | Options - General Tab - make sure it's set to Break on Unhandled
> Errors.[/color]

Interesting point. Given that the Tools -> Options submenu is
"grayed out" until you load a database, I had assumed that this
meant that all options were saved with the .mdb file. That and
the fact that at least one option (Compact On Close) most
definitely IS saved with the database.

However, I was wrong about this. In fact, this is one of the
murkiest and worst-documented features of Access. For instance,
in the online help page "Set Options from Visual Basic" there is
a note at the bottom of the page advising the developer to set
Error Trapping to 2, when a project is completed. However, the
fact that "Error Trapping" does NOT appear in the list of Options
that may be set from VBA code further reinforces the myth that
such settings are saved with the .mdb file. The inference is that
as long as you manually set the Error Trapping to "Break on
Unhandled Errors" before you send the file off to the customer,
all will be well...

However, the good news is that this is nothing to do with Access
2003 (there are some peculiar bugs in that edition but this is not
one of them).

And the moral of this story is: ALWAYS make sure that the
Form_Open() event procedure of your startup form contains this line:

Application.SetOption "Error Trapping", 2