AutoExec as vba instead? (1 Viewer)

[mistyinca1970]

I have an AutoExec macro that opens my login form. But I want to add some error handling because I forgot to log into our VPN this morning, and I got error 2950. So I want to have a message box deploy for that error. I used the convert feature, and it created it as a Function in a module. So here's what I've come up with. Do I name the module "AutoExec"? and disable the AutoExec macro? Thank you,

Function AutoExec()
On Error GoTo AutoExec_Err
    DoCmd.OpenForm "frmLogin", acNormal, "", "", , acNormal

Cleanup:
    Exit Sub
AutoExec_Err:
Select Case Err.Number
    Case 2950
      MsgBox "You must be connected to the Network on the County VPN to open Contrax™!", vbOKOnly, "Not Connected to Network"
    Case Else
      MsgBox "There is a problem opening Contrax™. Please contact the administrator.", vbOKOnly, "Contrax™ Not Available"
    End Select
   
    Resume Cleanup
End Function

 

[bastanu]

Name the function fnAutoExec and update the existing macro to run the function instead (of opening the form) using RunCode(fnAutoExec) action.

 

[mistyinca1970]

Name the function fnAutoExec and update the existing macro to run the function instead (of opening the form) using RunCode(fnAutoExec) action.

OK, and then what about naming the module? I vaguely remember something about module and function not being the same name...

 

[bastanu]

Yes, name the module modAutoExec or something similar.

 

[arnelgp]

you can run it without Renaming.
macro (script) is not same as function/sub (vba code).

you create another autoexec macro and
RunCode AutoExec()

 

[Isaac]

another approach is to skip the macro altogether and just specify a startup form (in Options > Current Database)
put any code you want in the form's load event

 

[arnelgp]

skip the macro altogether

based on the code, the Autoexec is already opening the First form (login form)?

 

[mistyinca1970]

based on the code, the Autoexec is already opening the First form (login form)?

Tried as a module and it works; however, it is not recognizing the "Case 2950" because it is popping up the "Else" message. Here's the fn code (below are some screenshots):

Function fnAutoExec()
On Error GoTo AutoExec_Err
    DoCmd.OpenForm "frmLogin", acNormal, "", "", , acNormal

Cleanup:
    Exit Function
AutoExec_Err:
Select Case Err.Number
    Case 2950
      MsgBox "You must be connected to the Network on the County VPN to open Contrax™!", vbOKOnly, "Not Connected to Network"
    Case Else
      MsgBox "There is a problem opening Contrax™. Please contact the administrator.", vbOKOnly, "Contrax™ Not Available"
    End Select
    
    Resume Cleanup
End Function

Without the function, when not connected to VPN, here is the macro error (2950). So by my code, it should show up the 2950 message...

But instead, it is showing the "else" message.

 

[Isaac]

Possibly the global err object is getting Cleared due to someone pressing "stop all macros", which means by the time it hits the error handler, there is no err.number, it's 0.
Remove the error handler entirely, then do whatever you do to generate the runtime error. After you get to the immediate window see what the err.number is by asking the immediate window that question

?err.number [then press Enter]
while in break mode

Going back to my original advice not to mix macros and vba, or use macros at all....

Just have a Form, that Form has code in its Load event, and you specify the database to open that form as the startup form (Options>current database), that is how most people code for the database first opening, or something very similar

 

[bastanu]

@Isaac -unless the form is bound and you need to do something with the tables (such a refresh links) as that will cause an error

 

[Isaac]

I see your point, I've just always resolved that by making sure never to load a bound form "first thing", prior to the startup things...

 

[mistyinca1970]

I see your point, I've just always resolved that by making sure never to load a bound form "first thing", prior to the startup things...

Interesting...by this do you mean not pop up the login form, and instead have a login link that will pop up the login form..? I'm going to try tinkering with that immediate window. The first time someone downloads and opens the Front end file, I'm getting this and its not handling it based on the 2950 scenario or the else scenario. It is being caused by having to enable content. Is there anyway to make it not prompt that. I assume it is unavoidable due to org IT policy.

 

[Isaac]

I was thinking an order like this:

1. set an unbound form as the database's Startup form (Access Options > Current Database > Display Form)
2. there, do anything you need to do to ensure/provide the user with a connection to any later bound forms. test their connection, create a connection, etc
3. finally, depending on the outcome of #2, load any forms that involve bound data or connections

If your users are presented with that enable content, and don't click it, all bets are off anyway - nothing automated is going to happen.

There are many threads that deal with the problem of trying to make your database more fool proof when it comes to Trusted Locations.
Search results for query: database trusted location | Access World Forums (access-programmers.co.uk)

 

[mistyinca1970]

I actually do already have the unbound form. It is frmOpen. Its a blank blue form so that the screen is aesthetically pleasing upon opening. The login screen just popup opens on top of that, and when it closes and the other form opens, it closes frmOpen.

So I'm thinking then instead of the autoexec. I can put a link to login after they Enable content. And that login link can be in the frmOpen, since I have that already in there....

I'm gonna chew on this for a bit and see what is the most elegant way for this to open without looking like something went wrong. A macro error box doesn't look good

 

[Isaac]

A macro error box doesn't look good

I know what you mean. Sounds like you are on a worthwhile pursuit.

I was just trying to think of any way to avoid that macro error box, and, at least you know for sure that when you run pure VBA code (non-macro), you can trap errors with elegant message boxes, etc.

Good luck chewing

 

[mistyinca1970]

Possibly the global err object is getting Cleared due to someone pressing "stop all macros", which means by the time it hits the error handler, there is no err.number, it's 0.
Remove the error handler entirely, then do whatever you do to generate the runtime error. After you get to the immediate window see what the err.number is by asking the immediate window that question

?err.number [then press Enter]
while in break mode

Going back to my original advice not to mix macros and vba, or use macros at all....

Just have a Form, that Form has code in its Load event, and you specify the database to open that form as the startup form (Options>current database), that is how most people code for the database first opening, or something very similar

Finally got this, and it's error number 3044... So I was able to address the issue of not being connected to vpn, and the appropriate message box. The other error happening when content is not enabled I can't test until I'm back in the office. I think I probably made this remote computer a trusted location, and so I can't recreate the error here. So this one is To be continued...

 

[Isaac]

don't know how small/unrestricted (versus large/highly restricted) an environment you may be in, but once i had my users run VBScripts to add trusted locations registry entries, which enables you to transcend that whole trust issue.

as far as training them to physically go into their Office app Options/Trust Center and add a specific trusted location, that may be another possibility. personally i can't seem to get that to work very well, but maybe others have had different experiences.

that's one thing i like about accdr/accde/Access runtime: instead of opening the whole dang database, all ugly in the background, and then inviting the user to Enable Content (and rectify the whole scene), the runtime scenario provides one, single, clean, professional-looking "open" or "allow" prompt prior to the database opening, or i should say prior to such time as it looks totally open. i find that much more attractive. at least that's the way it was last time i used runtime, which has been a while.

 

[theDBguy]

...the runtime scenario provides one, single, clean, professional-looking "open" or "allow" prompt prior to the database opening,...

I actually feel the same way. But as far as "professional looking" goes, I had the opposite experience. If you think about it, the first thing that notice says is "A potential security concern has been identified." I was told that some users find it intimidating, and they get scared from running the database. I guess you can't win them all.

 

[mistyinca1970]

There's a lot we can't do. We don't even have administrator access in our computers. This is a local government office, and all of our IT services are handled by another division.

 

[Isaac]

I actually feel the same way. But as far as "professional looking" goes, I had the opposite experience. If you think about it, the first thing that notice says is "A potential security concern has been identified." I was told that some users find it intimidating, and they get scared from running the database. I guess you can't win them all.

Yeah, that's a fair point. It's a professional but VERY serious-looking thing