Easiest Error trap?

  • Thread starter Thread starter Derek Brown
  • Start date Start date
D

Derek Brown

Hi all

I have code that maximises a main form when the current report is closed. I
have to do this because if a user clicks on the restore part of the control
box of a report (for whatever reason, god only knows why sometimes), when
the report changes size, the underlying form is also reduced. When the
report is then closed the user is faced with a reduced size main form.
Despite many attempts you cannot remove these minimise and restore parts of
the control box!! (which would solve the problem) despite the fact that the
help feature says that you can. The only problem with this is that if a
user chooses the Exit part of the main window control box as a way to close
the entire program, the code that runs on the report tries to maximise a
form that has already closed and causes an error, I need some code that says
if quitting the program ignore macros and code. and I need to know where to
"stick it"

Any suggestions?
 
instead of running code when the report closes, try running

DoCmd.Maximize

on the *form's* Activate event.

hth
 
Hi

By the way is there any way to stop the underlying form from changing size
when a report is changed?.
 
well, i usually set a form's Visible property to No when i open a report.
that way any control references are still valid, but you don't see the form.
on each report's Close event, i set the form's Visible property back to Yes.
and yes, you'll be faced with the same issues you had before when you were
Maximizing the form on the report's Close. you have two choices on how to
handle the issue:

1. trap the error that occurs when Access is closed while the report is
open, so that no error message occurs to the user (this assumes that you're
using VBA code, in the report's Close event; macros have no error-handling
ability.)

2. use any of the options at
http://home.bendbroadband.com/conradsystems/accessjunkie/closebutton.html to
remove the X button from the Access window. i personally have used #9 on the
list. note: make absolutely sure that you don't "strand" your user
somewhere in your database's user interface when s/he can't either quit the
application or move to another form that offers a Quit.

hth
 
Back
Top