messages to controls
messages to controls
Now i'm having a edit and button control. how the messages should be sent to the controls. should window get the message for the child control and then it should be posted to the child control (or) window manager is responsible for sending the message directly to the child control.
everyone here are best programmers ( not yet not yet)
Depends. Both approaches have their merits.
If the messages are posted to the child windows first, then the workload on the parent decreases significantly. It also ensures that the highest-zorder window gets the message first. For security, this method would be preferred. Otherwise a rogue parent window could intercept the messages or alter them. What about a 'secure' password textbox that returns encrypted text when you query its value? The parent could have just captured the keydown messages!
In the second approach, where the messages are posted to the parent windows first, the load on the window manager is lessened. (OTOH, the window manager should be tracking the focused window anyway, so at least for keyboard messages this shouldn't be a problem.) Parent windows could inspect (and act on) messages sent to children with focus. For instance, menu accelerators (Alt+F, S or Ctrl+S) for file save (windows world, obviously) would be much easier to implement.
So again it depends on the specifics of what you are trying to accomplish. But my recommendation would be to send mouse and keyboard messages directly to the child controls - it makes things simpler for the developers. Otherwise you have to check if the window has children, and if so, where they are or if any of them (or any of their children) have the focus.
My 2|C
If the messages are posted to the child windows first, then the workload on the parent decreases significantly. It also ensures that the highest-zorder window gets the message first. For security, this method would be preferred. Otherwise a rogue parent window could intercept the messages or alter them. What about a 'secure' password textbox that returns encrypted text when you query its value? The parent could have just captured the keydown messages!
In the second approach, where the messages are posted to the parent windows first, the load on the window manager is lessened. (OTOH, the window manager should be tracking the focused window anyway, so at least for keyboard messages this shouldn't be a problem.) Parent windows could inspect (and act on) messages sent to children with focus. For instance, menu accelerators (Alt+F, S or Ctrl+S) for file save (windows world, obviously) would be much easier to implement.
So again it depends on the specifics of what you are trying to accomplish. But my recommendation would be to send mouse and keyboard messages directly to the child controls - it makes things simpler for the developers. Otherwise you have to check if the window has children, and if so, where they are or if any of them (or any of their children) have the focus.
My 2|C
-
distantvoices
- Member
- Posts: 1600
- Joined: Wed Oct 18, 2006 11:59 am
- Location: Vienna/Austria
- Contact:
I'd have the window manager be mostly ignorant about events ... stuff like mouse down/up/over/out/ etc ... should go directly to the concerned window (i.e. the application owning the said window). the application then instructs the window manager about what to do (activate/deactivate/move/resize or something else depending on the control which gets the event in the end)
It's maybe like this:
window-manager gets mouse event from mouse driver. it checks the list of windows from top to down and the first one which is found is the one whose event thread gets the event posted to.
The event thread in the application fetches the message from its queue, checks: which of my windows. which of the controls inside of the window.
Trigger the control/window event handler. The control/window Event handler deals with the details of the given event in regards to the control/window dependant actions (mouse up, mouse down, etc get special treatment, for drawing f. ex.) and eventually calls a user registered event handler function which does stuff the user defines.
That's it mostly, from my point of view. Hope it helps you to get the stuff sorted out.
stay safe
It's maybe like this:
window-manager gets mouse event from mouse driver. it checks the list of windows from top to down and the first one which is found is the one whose event thread gets the event posted to.
The event thread in the application fetches the message from its queue, checks: which of my windows. which of the controls inside of the window.
Trigger the control/window event handler. The control/window Event handler deals with the details of the given event in regards to the control/window dependant actions (mouse up, mouse down, etc get special treatment, for drawing f. ex.) and eventually calls a user registered event handler function which does stuff the user defines.
That's it mostly, from my point of view. Hope it helps you to get the stuff sorted out.
stay safe
... the osdever formerly known as beyond infinity ...
BlueillusionOS iso image
BlueillusionOS iso image