When I click on button, might be in windows apps, web apps, etc it has some animation to actually see it clicked and event is raised in background. I’ve knowledge of events and its attaching to button click events but I wanted to know how this mechanism works. I always assumed it is inbuilt in operating systems.
2
- The mouse hardware sends very simple messages on the USB bus when appropriate, essentially “button x was pressed/released” and “moved this much in the x and y directions since the last message I sent.”
- The USB driver on the computer has either been polling for these messages (checking periodically), or receives an interrupt, which is a mechanism built into the hardware that says, “I have a new USB message so I’m running code at a particular location.”
- The USB driver passes the message to the mouse driver in the kernel.
- The mouse driver passes the message to the graphics subsystem (like xorg on Linux).
- The graphics subsystem keeps track of the absolute position of the mouse, updating it from the relative position messages the mouse driver sends.
- The graphics subsystem passes events to the window manager (like mutter).
- The window manager keeps track of which window is under the mouse, and passes click events to the windowing toolkit (like Qt) associated with that window.
- The windowing toolkit keeps track of which button is under the mouse, performs the click animation using graphics primitives, and passes events to subscribed listeners.
Obviously the implementation is different for different operating systems. In particular Windows lumps a lot of the layers together for the programmer and user point of view, but that’s the basic lay of the land. I gave you some names for Linux because those are open source and if you were so inclined you could trace everything from the silicon on up. Qt and other widget toolkits, which seems to be the part you’re most interested in, are also available for Windows.
It’s pretty amazing to contemplate the precise flow of electrons needed starting at the mouse button switch, through the CPU, out to the Internet and back through countless routers and servers, back through your CPU, eventually resulting in every single pixel on your display being commanded to its own specific color. We sum up that result of millions of hours of collaborative effort simply as “clicking a link.”
0
There really isn’t an interface. There is the object that raises the event and then a delegate(s) that handles the event. The object that raises the event has no idea who/what/how the event will be handled. It just raises the event with any relevant data on the message so that the delegate(s) can handle it properly.
The delegate has to register itself as a handler for that event.
Something like this:
button1.Click += new EventHandler(button1Click);
Then there will be the method that will handle the event:
void button1Click(object obj, EventArgs e)
{
//Do Something with the click
}
Its not garanteed that “Event Driven Programming Model” will exist on your platform or environment. It so happens on Windows that this is supported.
With .Net, the support is baked with the ability to raise events and use delegates to handle them. There also built in async support as well.
Underlying, the OS (Windows) has a message pump or loop which is constantly cycling and handling messages that are posted. Typically, in higher level languages you do not have to interact with the internals as these are shielded from you from the framework with namespaces such as System.Windows.Forms. But you can get close to the message pump by working with the Windows API directly (if you want to).
You can learn more abou the message pump here:
https://stackoverflow.com/questions/2222365/what-is-a-message-pump