Difference between Events and Methods in VBA

[davegoodo]

What is the difference between Events and Methods? The closer I've looked the more confusing it became. I thought I'd post a question.

How would you define the difference? Would you have a clarifying example?

Thanks

 

[Josef P.]

Perhaps this will help:
Please do not confuse event with event handler.
Event: an event is triggered, it cannot be called like a procedure/method in VBA. Events in their own classes are triggered in VBA with RaiseEvent.
Event handler: this is the method used to react to the event.

More (better) info:

Access/VBA - Event handling Tutorial (Part 1) - First steps for beginners

Extensive step by step tutorial on how to implement simple event procedures for beginner in VBA programming.

codekabinett.com

 

[davegoodo]

Thanks for the quick response. That has helped. I'll try out the link you referred to as well.

Much appreciated.

 

[arnelgp]

it cannot be called like a procedure/method in VBA.

they can be called if you made them Public.

 

[Josef P.]

Events can not be called like a procedure - only the event handler.

An example:
Class with events:

Public Event TestEventWithoutParam()  '<-- this is an event
Public Event TestEventWithParam(ByVal InfoText As String)

Public Sub DoSomeThing()

' Raise event TestEventWithoutParam
   RaiseEvent TestEventWithoutParam
'
' Raise event TestEventWithParam
   RaiseEvent TestEventWithParam("I like events!")

End Sub

=>Object Browser:

Use this class + events with event handler:

Private WithEvents m_InstanceOfMyClassWithEvents As MyClassWithEvents
' ... declaration with WithEvents!

Private Sub m_InstanceOfMyClassWithEvents_TestEventWithoutParam()  '<-- this is the event handler
' .. this is the event handler for the event MyClassWithEvents.TestEventWithoutParam
End Sub

Private Sub m_InstanceOfMyClassWithEvents_TestEventWithParam(ByVal InfoText As String)
' .. this is the event handler for the event MyClassWithEvents.TestEventWithParam
End Sub

 

[MajP]

What You Need to Know About Access Events

There is often a lot of confusion about Access Events and often answering questions posed here is difficult because of inaccurate terminology. People often say "Event" when it is unclear if they mean the actual event that takes place, the event procedure, or the event property. This thread...

www.access-programmers.co.uk

 

[arnelgp]

Forms/Reports in Access are classes also and you can make their Events Public and can be called directly.

 

[The_Doc_Man]

Access performs certain steps to process forms and reports , and these steps are always in a specific sequence. At several strategic points in this sequence, Access does some specific thing and then gives you a chance to add your own touch to what just happened. Access calls these important strategic points "events" and they related to various stages of form, report, and control processing. Whether you have code or macros or you have nothing for these strategic moments, the Access activity WILL occur.

For example, if you launch a form, the Form_Open event occurs when Access opens the container for the document that is the form's potential contents. The Form_Load event occurs when Access takes the things out of the form's container and places them in the window. The Form_Current event occurs (only for bound forms) when a record is opened or when record navigation occurs and the form displays the content of the record.

There are many possible events for forms, reports, and controls. In each case, whether you have declared a special action or handler routine or you left it blank, Access WILL do what is appropriate for the moment. But IF you declared something for that event, Access will ALSO execute your macro or call your event routine before proceeding to the next phase of the object's operation. The Access "internal" portion of the event executes before any code you add for the event. Also, if you have ever run across this term in other languages, the Event property provides a callback point for that event.

When you have controls on a form or report, they can have events as well. Control events fire starting with an Enter and GetFocus event. Your actions might trigger Change and update-related events. When tabbing out of a control, you can have the LostFocus and Exit events. Some items support Click events. Some support DblClick events. Labels don't support quite as many events as text boxes because labels are unbound and thus don't have any data-related functions.

Here is an article that talks about the various events and when they occur. Note that Access frequently defines a SEQUENCE of special milestones and therefore defines a corresponding sequence of event options.

Order of events for database objects - Microsoft Support

support.microsoft.com

A Method is (distilled down to its minimum) a subroutine intimately associated with a particular object (or object class) and callable in the context of that object. For instance, form-name.Maximize or form-name.Minimize to change the named form's presence on the display. Many objects have associated methods. To know what is available for an object, you can look up that object by its class-name to find out its properties and methods. So you might look up Access Form Properties or Access Form Methods to see a list of what you could do.

 

[Edgar_]

Methods and Events are both part of a class.
A method runs code.
An event is just a notification.
We can respond to that notification with a method, that would be called an Event Handler. The developers of MS Access gave us an intuitive list of event handlers that we can employ to handle those notifications. But you can create your own if you need it by creating custom classes.

An event is raised when a series of circumstances take place, for example: user actions. They are commonly done through something called "Observer Pattern", in which one or many objects are notified about things occurring to other objects. Because of the "closed" nature of MS Access, we can not employ with ease all of the sophistication of that design pattern, but we can raise our own custom events through VBA by taking advantage of the properties and methods that are exposed to us. You can learn a lot more by getting yourself into some Object Oriented Programming.

Hope it makes sense.

 

[Josef P.]

Forms/Reports in Access are classes also and you can make their Events Public and can be called directly.

The events of the Access.Form interface are always public, otherwise you would not be able to react to them.

Maybe I'm being a bit picky, but the difference between event and event handling is important for me.

Form.Open .. Event
Form.OnOpen .. property to set event handler (Value [Event procedure] activate VBA event handler Form_Open)
Form_OpenMe.Form_Open .. Event handler

An event can only be triggered in VBA with RaiseEvent. The event of the form interface is only triggered by the class that implements this interface.
We can only react to the Open event with the Form_Open event handler.

 

[arnelgp]

The events of the Access.Form interface are always public, otherwise you would not be able to react to them.

well, i get Private when i created code on the events .
when Private, it can only be called from Within itself.

 

[Josef P.]

You create the code for the event handling method in the class of your form. This is usually (and correctly) private.
You can of course also call this method, even if I advise against it from a "clean programming" point of view.

 

[arnelgp]

You create the code for the event handling method in the class of your form

it is the Event itself not any event handling.
did i Raise an Event when you put code to it?

 

[Josef P.]

Perhaps I should formulate it more precisely:
Form_Open is the method that handles the Open event.

A thought experiment:
Do you agree that several other instances could react to events of one specific instance?
If Form_Open were the event, you could in principle trigger it again at any time. Then other forms that also react to the Open event would have to be triggered again by calling Form_Open.

As pseudo code:
Form1:

Public sub Form_Open()
'
end Sub

Form2:

private withevents m_Form1Instance as Form

private sub Form_Current()
     set m_Form1Instance = Forms("Form1")
End Sub

private sub m_Form1Instance_Open()
   msgbox "Form1.Open raised"
end sub

some code in standard codemodule:

private sub Test()

    Docmd.OpenForm "Form1"
    Docmd.OpenForm "Form2"
 
    Forms("Form1").Form_Open

end Sub

If Form_Open is the event and not the event handler, the Msgbox should be displayed by the code in Form2.
But this will not happen.
Forms("Form1").Form_Open only calls the method.

---

Note:
In my opinion, twinBasic allows a more comprehensible way of describing event handling.
VBA:

private Withevents MyInstance as Form

Private Sub MyInstance_Open()
  ' this handles Open event of Form interface.
End Sub

twinBasic:

private Withevents MyInstance as Form

Private Sub MyOwnProcedureName() Handles MyInstance.Open
  ' this handles Open event of Form interface.
End Sub

 

[The_Doc_Man]

It should be noted that the word "Event" is multi-layered in this discussion in this sense: Windows also declares certain things as program "events" and they have the implication that the MAIN program could, if it wanted to, respond to those Windows events, some of which are capable of interrupting program flow.

The difference is that for Access, an event is NOT always related to an interrupt but rather to significant milestones in the orderly processing of objects that have such milestones defined as part of their interface. Most milestone events occur SYNCHRONOUSLY (though user actions that affect content or focus CAN trigger an event, e.g. button Clicks, keyboard clicks, mouse clicks). It should also be noted that for any given user session, events cannot interrupt each other. They are queued for linear execution and, unless you perform an action to alter event code flow, non-stop in their operation. The exception is a call to routine DoEvents, which pauses the event code currently running, makes a place-marker for the next instruction in the event code, and drops that marker at the tail end of the pending event queue.

 

[gemma-the-husky]

I think an event is rather like the tree falling in the forest. Millions of events happen, but they have no effect until you add code to respond to the event.

I presume the events still occur, anyway. Is there an event history that can be examined somehow?

 

[Pat Hartman]

If you want a way to understand when events fire, take a look at this sample database. I recommend that you watch at least one of the videos so you have some understanding of how to use the forms in the database.

P

Thread 'Bad Data is Bad for Business #1 and #2'

Aug 11, 2022

I just added #2 --- that link is further down. It is much shorter than #1. I also added a copy of the database I used for the video. Enjoy

I created a database to help people to understand how and why to use the Form's BeforeUpdate event to validate data. @Uncle Gizmo and I made a video to talk about the example. It's about a half hour long. Please take a look if you have time and we'd love to hear your comments.

You should be able to click on play without having to create an account.

Bad Data is Bad for Business - Pat & Tony (screencast-o-matic.com)

I have a...

• Pat Hartman
• Replies: 38
• Forum: Microsoft Access Tutorials

• 

I presume the events still occur, anyway.

The events always occur when the action that triggers them is performed. If you don't open a form, then the fom's Open event procedure would never run to execute your code. If you don't use the mouse to click into a control, focus can still enter the control but the Click event of the control will not fire, just the GotFocus and Enter events would fire. If you do Click, then all three events fire.

The Form or Report's Class module provides all the code needed to open and render and manage a form or report. The events that are exposed are like hooks for us to hang our code on. We can leave the hooks unused (no code/macro) or we can add code or a macro that the form/report's class module will call should the relevant event be raised.