Question Switchboard Reset on Error

[GUIDO22]

Hi All
I have an error that has haunted me for some years now. I have identified the problem I just need a practical way to avoid it. Here goes...

I use a Switchboard panel arrangement from which all forms/reports are displayed. When the Switchboard form loads - first sub called is UpdateLoginInfo() which determines the CurrentUserGroup and sets the value of the nUserGroup var. The Switchboard buttons are given Enabled/Disabled status by way of a value defined in the Switchboard Items table. This flag value is compared to thenUserGroup var to allow/prevent use of that Switchboard panel option. The Switchboard Items table is queried each time the Switchboard panel is refreshed with a new set of buttons. The Switchboard panel remains open throughout the duration of the database session and only closes when the user quits.

My error handling isn't what it should be (I guess), and some of my users get the occasional error that prompts with the Access error message dialog and the End / Debug button options. When the End button is pressed - the application halts and resets(?). However, the Switchboard form is still open, so when the user returns to this form from the error and refreshes pressing one of the Switchboard buttons, when it redisplays the Switchboard panel with its new set of buttons - all button options are Disabled. I have determined that this is becuase the nUserGroup variable has been re-initialised to 0, (presumably when the user selected End from the error msg dialog). I could initialise the nUsergroup variable each time the Switchboard panel refreshes but that seems a bit of a 'fudge'.

Where am I able to trap this generic Access End/Debug error and force the Access application as a whole - to terminate in this situation ?

TIAFAH

Guido

 

[boblarson]

I would try to make it happen and press DEBUG instead of END to find out why it is happening and then deal with it there.

 

[GUIDO22]

Bob
I know why the error happening because on this occasion I INTENTIONALLY put a flaw in the code to enable me to determine exactly why the Switchboard panel was resetting all of the button options!

My query is not related to the specific nature of the error - I just need a solution to force the application to close in the event of a non-handled error event. If there are other bugs in the code that presently I do not know about - at least this will prevent future USER confusion when they find aforemtioned bug and the panel is all greyed out and they cant do anything....!

Regards
G

 

[boblarson]

The only thing I can think of is to make sure to include error handling on all of your procedures so that you never have an unhandled error. Handled errors will not reset your variables.

 

[GUIDO22]

Bob
So there is nowhere that I could place a generic error handler to trap all other unhandled error events?

 

[boblarson]

Bob
So there is nowhere that I could place a generic error handler to trap all other unhandled error events?

There may be, but not that I'm aware of.

But, it is easy (using the free MZ Tools - http://www.mztools.com) to just go into your procedures and add an error handler with a click of a button. You don't need one everywhere but just in any procedure that has any chance of failure.

 

[GUIDO22]

Thanks for the MZ tip. Respectfully, I am not too sure we are on the same wavelength here - I need to prevent the Switchboard panel from being accessed when any error occurs.

There may be some other bugs in my code that presently I am not aware of. Sure these will likely come out in the fullness of time - but in the meantime I would like to prevent Switchboard panel access after said bug has appeared....

I have also noticed that when this happens - if the DB is closed but the Access application window remains open - if the users start the DB again from the MRU list - the Workgroup security login dialog does not prompt (as it should do) and user is taken striaght into the Switchboard panel. Does Acess assume the previous login details in this instance?

Thanks for your comments.