You may want your application to behave differently on your development machine to how it behaves on the client’s machine. To do this, create a ‘secret’ text file, for example DevsComputer.txt, to identify that this computer is your developer’s computer. I put it in the root directory (C:\DevsComputer.txt) so it is easily accessible to applications in any folder. When you need your application to behave differently, just check for the existence of your secret developer file with the following code.
If Dir(“C:\DevsComputer.txt”)<>”” Then
You could run this procedure when the application opens and set a global variable which you can more easily access from anywhere in the application.
Global gDevMode As Boolean
gDevMode = Dir(“C:\DevsComputer.txt”)<>””
in any procedure …
If gDevMode=True Then
I usually use this to turn on or off various environment variables such as the AllowBypassKey, AllowSpecialKeys, AllowFullMenus, Show Hidden Objects. It is also useful for debugging as described in the next section. And when the application quits, I use it to have the application return to the database window for more development, while it quits completely on the client’s machine. If you want to look at how the application will work on the client’s machine, just rename the text file so it can’t be found. I usually just put an x in front, e.g. xDevsComputer.txt.
Then I can easily remove the x when I want to go back to developer mode. If you are working on site, you can create the text file on the client’s computer if you need to use specific developer features. But don’t forget to delete it before you leave! (Might be a good idea to remove it from the recycle bin too.) This process is not particularly secure if your clients are inclined to view your code. You may need to consider the likelihood of this happening and how it might compromise your application.
Generic error handler +/- logging.
When developing an application, I want the code to show me the exact line where an unexpected error occurred. The code below shows you the error message, then you can choose whether to continue with the normal error handling routine, or whether to break into the code. If you go to the code, hit the F8 key twice to go to the line that caused the error. The key is to use the Resume statement – but this should never be used except in break mode or the app may go into an infinite loop.
Private Sub RunSomeCode()
On Error GoTo ErrHandler
<Your code here >
Select Case Err.Number
Case XXX 'For a specific error, add code here to manage that error
<Your error management code for specific error>
Resume Next 'Or Resume or Resume ExitHere
If ShowGenericErrorMessage("RunSomeCode") = True Then
Resume 'To manually debug
Public Function ShowGenericErrorMessage(ProcName As String) As Boolean
'Don't add any error code to this procedure since it will reset the Err
'to 0 and prevent the error being displayed.
'Called by various error procedures
'If false the code continues in the calling procedure
'If true the code stops in debug mode in the calling procedure
'Reset the environment in case it had been modified by the calling procedure
If Dir("C:\DevsComputer.txt") <> "" Then
ShowGenericErrorMessage = MsgBox("The following unexpected program error” & _" has occurred:" & _
vbCrLf & vbCrLf & "Module: " & _ Application.CurrentObjectName & vbCrLf & _
"Procedure: " & ProcName & _
vbCrLf & "Error number: " & Err & vbCrLf & "Description: " & Error & _
vbCrLf & vbCrLf & "Do you want to debug the program code?", vbExclamation + _
vbYesNo + vbDefaultButton2, "Unexpected application error") = vbYes
MsgBox "The following unexpected program error has occurred:" & vbCrLf & _
vbCrLf & "Module: " & Application.CurrentObjectName & vbCrLf &
"Procedure: " & ProcName & vbCrLf & "Error number: " & Err & _
vbCrLf & "Description: " & Error & vbCrLf & vbCrLf & _
"Please inform technical support. ", vbExclamation, _
"Unexpected application error"
ShowGenericErrorMessage = False