Click Events in .NET
-
Here's something I wish to learn about how Windows OS interacts with .NET: Every Windows Forms Control has the ability to handle one or more mouse actions - left click, double click etc. For example, .NET allows this by generating a Click event for the relevant control everytime the mouse is left clicked. What I wish to understand is that how does .NET know which Control to generate the Click event for. In other words, if I click on a particular button, the OS recognizes the point on the screen where the click occurs, then translates that information and sends it to .NET which identifies which control does the click correspond to. That, at least, I believe is the chronology. But I'm not sure how this translation between the OS and .NET takes place. Any help is greatly appreciated. Thanks.. Sarabjit.
-
Here's something I wish to learn about how Windows OS interacts with .NET: Every Windows Forms Control has the ability to handle one or more mouse actions - left click, double click etc. For example, .NET allows this by generating a Click event for the relevant control everytime the mouse is left clicked. What I wish to understand is that how does .NET know which Control to generate the Click event for. In other words, if I click on a particular button, the OS recognizes the point on the screen where the click occurs, then translates that information and sends it to .NET which identifies which control does the click correspond to. That, at least, I believe is the chronology. But I'm not sure how this translation between the OS and .NET takes place. Any help is greatly appreciated. Thanks.. Sarabjit.
I think it is done the way normal Windows apps do, through a Window procedure that is called from a message loop. The window procedure simply calls the delegates registered for that event. The Winforms button is a normal Windows button wrapped in managed code. There are no native .NET UI controls, AFAIK Regards Senthil
-
I think it is done the way normal Windows apps do, through a Window procedure that is called from a message loop. The window procedure simply calls the delegates registered for that event. The Winforms button is a normal Windows button wrapped in managed code. There are no native .NET UI controls, AFAIK Regards Senthil
Thanks for the help.. Though I'm still not completely clear: "The window procedure simply calls the delegates registered for that event" As per my impression, delegates that make calls to the respective event handlers whenever an event for a Control is raised are invoked inside the Control itself. Thus, to "simply call the delegates," the Windows procedure should first be able to identify which Control is it going to call the delegates of. Thus, either Windows directly makes a call to this Control, or it simply passes the event to the active process, which (by virtue of routines that were directly added by .NET when the program was compiled) then makes a call to this Control (specifically, to the OnEventName() method within the definition of this control). In both these cases however, there needs to be a way to identify which Control (button, scrollbar etc.)does the specific click correspond to. In other words, a literal translation between the co-ordinates of the pointer when the mouse was clicked and the Control the pointer was above at that time takes place. It is this translation that I need to get at the root of. "The Winforms button is a normal Windows button wrapped in managed code. There are no native .NET UI controls" I think you're right. I guess the .NET's only purpose - like that of any runtime environment - is to successfully compile and debug the code, adding any extra routines that it might need to. A few examples of such actions which are relevant to our context here and which .NET directly takes care of are: 1. Delegate definitions - A delegate declaration is sufficient to define a delegate class. The declaration supplies the signature of the delegate, and the common language runtime provides the complete implementation. 2. Event Wiring - A designer such as Visual Studio .NET automatically completes the event wiring by generating code which is necessary for the purpose. 3. Event Hooks - When the compiler encounters an event keyword (such as - public event HandlerNameEventHandler HandlerInstant;), it creates a private member such as and two public methods: add_Alarm and remove_Alarm. These methods are event hooks that allow delegates to be combined or removed from the event delegate. The details are hidden from the programmer. (The above are taken from the MSDN Library: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconevents.asp) Once the self-executable/dll is ready, .NET I believe is out of the pictu
-
Thanks for the help.. Though I'm still not completely clear: "The window procedure simply calls the delegates registered for that event" As per my impression, delegates that make calls to the respective event handlers whenever an event for a Control is raised are invoked inside the Control itself. Thus, to "simply call the delegates," the Windows procedure should first be able to identify which Control is it going to call the delegates of. Thus, either Windows directly makes a call to this Control, or it simply passes the event to the active process, which (by virtue of routines that were directly added by .NET when the program was compiled) then makes a call to this Control (specifically, to the OnEventName() method within the definition of this control). In both these cases however, there needs to be a way to identify which Control (button, scrollbar etc.)does the specific click correspond to. In other words, a literal translation between the co-ordinates of the pointer when the mouse was clicked and the Control the pointer was above at that time takes place. It is this translation that I need to get at the root of. "The Winforms button is a normal Windows button wrapped in managed code. There are no native .NET UI controls" I think you're right. I guess the .NET's only purpose - like that of any runtime environment - is to successfully compile and debug the code, adding any extra routines that it might need to. A few examples of such actions which are relevant to our context here and which .NET directly takes care of are: 1. Delegate definitions - A delegate declaration is sufficient to define a delegate class. The declaration supplies the signature of the delegate, and the common language runtime provides the complete implementation. 2. Event Wiring - A designer such as Visual Studio .NET automatically completes the event wiring by generating code which is necessary for the purpose. 3. Event Hooks - When the compiler encounters an event keyword (such as - public event HandlerNameEventHandler HandlerInstant;), it creates a private member such as and two public methods: add_Alarm and remove_Alarm. These methods are event hooks that allow delegates to be combined or removed from the event delegate. The details are hidden from the programmer. (The above are taken from the MSDN Library: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconevents.asp) Once the self-executable/dll is ready, .NET I believe is out of the pictu
My guess: The ability to perform this information transfer and detect the specific Control whose delegates need to be referenced in response to the particular event is NOT performed by the Operating System but by the process - the application itself. However, the routines to achieve this are not written by the application programmer. They are instead a part of the specific libraries the programmer includes in his project. As a result, these are included in the application at compile-time by the respective compiler (the .NET compiler in this case). After all, it is the environment's job to provide the I/O interface to the application programmer. AFAIK.. Any thoughts're welcome.. Cheers..
-
Thanks for the help.. Though I'm still not completely clear: "The window procedure simply calls the delegates registered for that event" As per my impression, delegates that make calls to the respective event handlers whenever an event for a Control is raised are invoked inside the Control itself. Thus, to "simply call the delegates," the Windows procedure should first be able to identify which Control is it going to call the delegates of. Thus, either Windows directly makes a call to this Control, or it simply passes the event to the active process, which (by virtue of routines that were directly added by .NET when the program was compiled) then makes a call to this Control (specifically, to the OnEventName() method within the definition of this control). In both these cases however, there needs to be a way to identify which Control (button, scrollbar etc.)does the specific click correspond to. In other words, a literal translation between the co-ordinates of the pointer when the mouse was clicked and the Control the pointer was above at that time takes place. It is this translation that I need to get at the root of. "The Winforms button is a normal Windows button wrapped in managed code. There are no native .NET UI controls" I think you're right. I guess the .NET's only purpose - like that of any runtime environment - is to successfully compile and debug the code, adding any extra routines that it might need to. A few examples of such actions which are relevant to our context here and which .NET directly takes care of are: 1. Delegate definitions - A delegate declaration is sufficient to define a delegate class. The declaration supplies the signature of the delegate, and the common language runtime provides the complete implementation. 2. Event Wiring - A designer such as Visual Studio .NET automatically completes the event wiring by generating code which is necessary for the purpose. 3. Event Hooks - When the compiler encounters an event keyword (such as - public event HandlerNameEventHandler HandlerInstant;), it creates a private member such as and two public methods: add_Alarm and remove_Alarm. These methods are event hooks that allow delegates to be combined or removed from the event delegate. The details are hidden from the programmer. (The above are taken from the MSDN Library: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconevents.asp) Once the self-executable/dll is ready, .NET I believe is out of the pictu
If you've done MFC programming, you would have got a clearer picture. Every widget you see in a windows application (well, almost most of them) are windows by themselves. A button is a window, a textbox is a window and so on. Every window has a window procedure which is invoked by the OS (once you register it, of course). The OS takes care of figuring out which input goes to which window and calls the appropriate WndProc. For eg, for a button class void WndProc(MSG message, LPARAM lParam, WPARAM wParam) { switch(message) { case WM_BUTTONCLICK: // Code for invoking the delegate } } If it is not handled by a window, it passes it to the parent window and so on. So you can have a single WndProc in the topmost window handle all messages for you. So it's Windows that takes care of it, not .NET. That's the difference between Java's Swing and .NET. Swing does all painting/event handling by itself. "Once the self-executable/dll is ready, .NET I believe is out of the picture." Not really, it's during runtime that the .NET Runtime and CLR play important roles like GC, CAS etc.. Regards Senthil
-
If you've done MFC programming, you would have got a clearer picture. Every widget you see in a windows application (well, almost most of them) are windows by themselves. A button is a window, a textbox is a window and so on. Every window has a window procedure which is invoked by the OS (once you register it, of course). The OS takes care of figuring out which input goes to which window and calls the appropriate WndProc. For eg, for a button class void WndProc(MSG message, LPARAM lParam, WPARAM wParam) { switch(message) { case WM_BUTTONCLICK: // Code for invoking the delegate } } If it is not handled by a window, it passes it to the parent window and so on. So you can have a single WndProc in the topmost window handle all messages for you. So it's Windows that takes care of it, not .NET. That's the difference between Java's Swing and .NET. Swing does all painting/event handling by itself. "Once the self-executable/dll is ready, .NET I believe is out of the picture." Not really, it's during runtime that the .NET Runtime and CLR play important roles like GC, CAS etc.. Regards Senthil