i want every time insert this code to change (Somename) to the event name, like :
Code:
Private Sub grpcmbo_AfterUpdate()
On Error GoTo Err_grpcmbo_AfterUpdate ' Initialize error handling.
"Mycode
' Code to do something here.
Exit_grpcmbo_AfterUpdate: ' Label to resume after error.
Exit Sub ' Exit before error handler.
Err_grpcmbo_AfterUpdate: ' Label to jump to on error.
Select Case Err.Number
Case 9999 ' Whatever number you anticipate.
Resume Next ' Use this to just ignore the line.
Case 999
Resume Exit_grpcmbo_AfterUpdate ' Use this to give up on the proc.
Case Else ' Any unexpected error.
Call LogError(Err.Number, Err.Description, "grpcmbo_AfterUpdate")
Resume Exit_grpcmbo_AfterUpdate
End Select
End Sub
in the form_current event change to :
Code:
Private Sub Form_Current()
On Error GoTo Err_Form_Current ' Initialize error handling.
"Mycode
' Code to do something here.
Exit_Form_Current: ' Label to resume after error.
Exit Sub ' Exit before error handler.
Err_Form_Current: ' Label to jump to on error.
Select Case Err.Number
Case 9999 ' Whatever number you anticipate.
Resume Next ' Use this to just ignore the line.
Case 999
Resume Exit_Form_Current ' Use this to give up on the proc.
Case Else ' Any unexpected error.
Call LogError(Err.Number, Err.Description, "Form_Current")
Resume Exit_Form_Current
End Select
End Sub
I think your question is about how to add lines of code to your VBA source code for every event in every class module or general module, and you want to do this programmatically rather than manually. Before we take a shot at this, could you please verify that this is what you want to do? If not, then your question isn't clear.
I will add that to do this, you had better be prepared to do text parsing on a massive level using VBA to accomplish this. There is also the chance that you might be able to get away with this via cut-paste of a common set of code lines that would be usable in event code because for forms/reports, the event code in a class module is always PRIVATE and thus its internal labels are not visible externally. But before we shift gears to this problem, it is massive enough that we would need some confirmation of direction.
I think your question is about how to add lines of code to your VBA source code for every event in every class module or general module, and you want to do this programmatically rather than manually. Before we take a shot at this, could you please verify that this is what you want to do? If not, then your question isn't clear.
First, you cannot do this to a .MDE or .ACCDE file - because that is already compiled. It has to be on an .MDB or .ACCDB, where the modules are all still in TEXT mode.
Second, each module has similar structure, which you can find by looking up the Module object using MSDN or other web searches. You can look at the lines of code in each module as members of the module.Lines collection, i.e. a property of a Module object.
Each line is self-contained as a string. As such, you can do things like InStr() and Mid$() and Left$() and Right$() functions to pick apart the line to see if it contains what you want as an action point. You can re-write the line by simply storing the line in the same line number, i.e. module.Lines = "...string...". You have to be careful because you can write anything you want, but it still has to compile correctly before it will run.
Third, once you find the place where you want to add your code, you can do a Module.InsertLines(ref#, string) call to insert a line AFTER the referenced line number. There are other functions you can apply. I advise you to visit MSDN and look at the methods and properties available for modules.
Fourth, each Form and Report has the option of a single class module, which is a module object found via the Form.Module property. Class modules don't have a separate name string particularly associated with them. However, the class object (Form or Report) has a property called .HasModule, which is FALSE if the object doesn't have a module.
Fifth, you can have a large number of General (i.e. not Class) modules as part of the application.Modules collection. I.e. CurrentDB.Modules(1).Name is the name of the first General module in your database.
Which means, ... sixth, you need TWO (or THREE) collection enumeration loops to find all the modules to be affected - one for Forms.Module, one for Reports.Module, and one for application.Modules. So structurally, you are better off if you make one subroutine to do what you want and call it from each of the three loops.
The collection enumeration loops are of two types:
Code:
For each modX in CurrentDB.Modules
loop body here based on modX
next
For each frmX in CurrentDB.Forms (or CurrentDB.Reports)
loop body here based on Form.Module or Report.Module
next
Now, one last consideration: There will be NO event code directly called in any general module, because events are associated with Class objects like Forms and Reports only. I was giving you the general description of updating any module code. But you are not likely to have to do this to a general module.
In fact, you will have only some fixed names to consider. Let's say, for the sake of discussion, that you wanted to do something to the Form_Current event handler. ALL events - of any flavor of event created by a form wizard - will be of type "Private Sub Form_eventname" and will end with an "End Sub" line.
The important thing to know is that you can safely insert a constant sequence JUST BEFORE the End Sub and can feel confident that you will minimally disrupt program flow. However, if the event in question already has an event handler (and some events created by the wizards WILL have this), you probably need to manually inspect cases where you would introduce a conflict. When reading the module, you might wish to see if any line in each declared Sub has an On Error clause in it, and skip the ones that do. In the SIMPLEST case (no previous event handler), you can try this approach...
1. Find the line with the Private Sub Form_eventname declaration
2. Insert after it a line that says "On error GoTo Falcon_Trap_Handler"
3. Find the End Sub line
4. Insert BEFORE it a set of lines that might look like:
Code:
Exit Sub
Falcon_Trap_Handler:
Select Case Err.Number
Case 9999 ' Whatever number you anticipate.
Resume Next ' Use this to just ignore the line.
Case 999
Resume Exit_Form_event ' Use this to give up on the proc.
Case Else ' Any unexpected error.
Call LogError(Err.Number, Err.Description, "Form_Current")
Resume Exit_Form_event
End Select
Of course, you substitute the _event part of each label for the actual event name.
This works because in a Private subroutine, you can re-use the same labels as you use in other private subroutines. Access will keep them private AND LOCAL. So no name conflicts, which is why I chose the name I did. Second, that which occurs on Form A is invisible to Form B (and vice versa) so using the same label names for the same events in different modules (particularly class modules) is perfectly safe. I added the "Exit Sub" line because there was no event handler so there would not have been a wizard-built set of logic with an Exit Sub to prevent you from "falling into" the handler code.
This might be enough to help you get started. I won't write more code than this because it is going to depend on what you wanted to do in deep detail, and this is YOUR problem, not mine. But maybe this will be enough to at least point you in the right direction.
sneuberg's posts are interesting. Falcon88, you might want to look at the cpearson.com link first. It is, in my opinion, a better reference to show you what that kind of code might resemble. The stackoverflow link, while relevant, includes some issues of personalities and opinions to be considered before lifting anything wholesale out that link.
I would recommend you don't add error handling to every procedure. In some procedures it just makes for unnecessary clutter.
When a error occurs in a procedure without error handling, it is passed up to the calling procedure. In many cases this is sufficient information for the developer to track down the error.
The main features I use are the Add Error Handler and Sort Procedures. It is nice to be able to drag and drop the procedures in a list to get a logical order rather then the default alphabetical order.
collection, i.e. a property of a Module object. 
