Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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.

share|improve this question
    
there are the mouseover, mouseout, mousedown and mouseup events with which you can emulate them –  ratchet freak May 21 '13 at 19:25
    
yeah, what I intend to know is how these mouse movements are captured by computer and eventually how events are fired. –  Sunny May 21 '13 at 19:38

2 Answers 2

up vote 5 down vote accepted
  1. 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."
  2. 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."
  3. The USB driver passes the message to the mouse driver in the kernel.
  4. The mouse driver passes the message to the graphics subsystem (like xorg on Linux).
  5. The graphics subsystem keeps track of the absolute position of the mouse, updating it from the relative position messages the mouse driver sends.
  6. The graphics subsystem passes events to the window manager (like mutter).
  7. 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.
  8. 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."

share|improve this answer
1  
+1 for that last paragraph. –  Bart van Ingen Schenau May 22 '13 at 7:56

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:

http://stackoverflow.com/questions/2222365/what-is-a-message-pump

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.