The difference between event handlers and callbacks

Question

What is the difference between an event handler and a callback function?

Answer 1

Generally speaking, the "callback" is under the control of the discovery process. Thus, you tell the GUI manager to “call myaction when this button is clicked”, and the GUI manager invokes the action when the button is clicked.

Event handlers, on the other hand, work in one step. The graphical user interface manager is configured to send messages to the event handler. You inform the event manager that button presses are processed by myaction . When the button is pressed, the GUI manager places the message in the event handler queue and starts GUI management. The event handler receives a message from the queue, sees it by pressing a button, launches the myaction program and proceeds to process the next event. Normally, myaction runs as an independent thread, or even as a separate process.

Although the event handler pattern is more complex, it is much more robust and less susceptible to freezing when an action fails. It also makes for a more responsive GUI.

Answer 2

A callback is a procedure that you pass as an argument to another procedure. A procedure that receives this parameter can call it or share it so that some other procedures in the system can call it.

An event handler is a procedure that is called when an event occurs. It could be a callback.

Answer 3

An event handler is a type of callback. It is called whenever an event occurs. This term is commonly used in terms of user interfaces, where events are things like mouse movement, click, etc.

Answer 4

Callback (from Wikipedia) : "executable code that is passed as an argument to another code."
Event handler (again from Wikipedia) : "an asynchronous callback function that processes the inputs received in the program."

Which happens as I always understood: an event handler is a very specific type of callback.

Answer 5

This question is very old, but I found this link from MSDN very interesting. I hope someone else who stumbles on this question gets something from this link.

Answer 6

Events . Think about the server (employee) and client (boss). One employee can have many bosses. Employee Raises an event when he finishes a task, and bosses can decide whether to listen to an Employee event or not. The employee is the publisher, and the boss is the subscriber.

Callback . The boss specifically asked the employee to complete the task, and at the end of the task, the boss wants to receive a notification. The employee will make sure that when the task is completed, he notifies only the boss who requested, and not all of the bosses. The employee will not notify the Boss if partial work is being performed. It will be only after everything is done. Only one boss requested information, and an employee only sent a response to one boss.

Answer 7

Another aspect of this is that events describe what happened in the past, while callbacks are often used when something happens.

When an event occurs, you are informed that something happened. When a callback is used, you are asked to participate in something.

A library or infrastructure can issue events that let you know that something has happened. The structure offers you points at which you can connect the code (possibly as callbacks) so that you can actively participate in the process.

Part of the problem is that the event, the callback refers to technical methanism, as well as to more abstract processes.

Answer 8

James Anderson's answer is the most detailed. Extension of his answer; A callback refers to any code that is passed as an argument to a method that should be called later asynchronously. However, the callback does not determine how the callback process itself should be performed. This is where the callback classification begins. Traditionally, the callback process will look like:

• the developer defines a callback and passes it to a specific library function (one that knows what to do with the callback so that the calling process or the discovery process can call it), for example. in node

var server = require('http').createServer(function(req, res){/* your code */});

createServer is a library-defined function that ensures that the discovery process gets the opportunity to call the correct callback, which in this case is function(req, res){/* your code */}

• at runtime, the discovery process gets the direct location of the callback (because the function defined by the library did this for you) and calls it. That would mean 2 things:
  • library developers should always know how to handle different discovery processes, since each of them may have a different way of calling
  • and if the callback needs to be called several times, this can trigger the discovery process. E.g. if the discovery process is a graphical interface, then you want the GUI thread to run with the highest possible task to ensure a smooth graphical interface.

Thus, there was a need to implement a callback mechanism that solved these 2 problems:

• an external process that will determine the parallel point for the library function for registering callbacks and for the discovery process to notify when these registered callbacks should be called.
  • This meant that the developers of both of these processes can now work independently of each other, without knowing each other.
  • This external process became known as an event loop (in node, for example). The term “event” is simply the process of notifying the event loop by the detection process, and the registered callback has become known as the event handler.
• an external process (or a cycle of events) queued up events and executed them, thereby removing the load from the discovery process, which can now resume in all that it does.

Thus, for events that happened several times, the event loop or event handlers have become a way to implement callbacks, while the original callbacks are still preferable for one-time events, since you really do not have to perform the discovery process and do not need to have an event loop for only one event because it is inefficient.

• The node js code above is a one-time event (since the connection to the server for the client is a one-time event, while there can be many responses that are implemented as event handlers) and is an example of a simple callback.

Answer 9

The basic mechanisms are similar, but the semantics are different. Both callbacks and event handlers are called asynchronously .

The callback function is usually passed explicitly from the call procedure to request some information. The information returns after some time, passed as arguments back to the callback of the called party. At this time, the call procedure completes your business. Often a callback is a closure - syntactically inside the calling routine and often unnamed (anonymous). This may look a bit like in javascript:

 function caller() { someLibrary.getMeSomething(arg1, arg2, function(returnedData) { // this is the callback which will do something with returnedData }); } 

Thus, the called party (someLibrary.getMeSomething) is provided with an anonymous callback function, and after a while this function is called using the returned data. The callback is like a one-time event to a single receiver.

Event handlers are also "returned", but they are usually used for a long period for several events, such as mouse clicks, network events, etc. In addition, several objects may be interested in the same event. For these reasons, you usually “subscribe” or “register” for events in the installation code (for example, initializing objects), and the event handler is usually a named method. Typically, each type of event is also identified as a constant or string.

So, in Python, it might look like this:

 class MyUIClass: def __init__(self): someUILib.register(someUILib.events.MOUSE_CLICK, self.my_mouse_click_handler); def my_mouse_click_handler(self, eventInfo): # do something with event if eventInfo.x < 100: print 'You clicked in the margin' 

Answer 10

I love how all these answers differ from each other.

I would conclude from this that, in terms of terminology, events and callbacks are interchangeable. What do they mean in a particular programming language or framework and are different from each other, since any platform tends to choose their favorite terms.

Answer 11

A callback is a function (method) that you pass as an argument to another function (method). A function (method) that takes a parameter can call it or share it so that another function (method) in the system can call it.

An event handler is a function (method) that is called when an event occurs. It could be a call back.

Answer 12

An event handler is a callback from the system.