Results 1 to 12 of 12

Thread: Input keyboard and mouse messages working different

  1. #1
    Lesser Knight
    Join Date
    Sep 2006
    Location
    Barcelona, Catalonia
    Posts
    30

    Default Input keyboard and mouse messages working different

    Hi, I'm trying to figure how can I manage inputs to my application, but I'm having some problems understanding it. I have a big custom CL_GUIComponent with some children, that are receiving mouse events correctly. On the other hand, keyboard inputs only are received on their parent, so I would like to ask you if it is the correct behavior.
    I suppose that keyboard inputs only are sent to the focused widget? The children never get the focus, by the way (I don't know why).

    Finally, I'm trying to use func_filter_message in order to avoid mouse inputs being sent to a transparent widget , but they still are sent, no matter I consume them in the filtering method, implemented in the father...I saw the a set_clickthrough method existed before, but it has been removed by the new filter_message.

    Thanks for your help!

  2. #2

    Default

    I suppose that keyboard inputs only are sent to the focused widget? The children never get the focus, by the way (I don't know why).
    Yes, keyboard input goes to the focused widget. If the focused widget doesn't consume the message, the message is sent up to the parent components and finally the gui managers dialog input handling routines and the accelerator table. There's a detailed (and accurate) description here: http://clanlib.org/docs/clanlib-2.0....i_details.html)

    No component gets focus automatically. If you want a component to be focused at application startup you should call set_focus() on it manually. For components that get focused when you click them you should handle that in the components message handler. For instance CL_LineEdit calls CL_GUIComponent::set_focus() in the mouse click handler. If you want custom components to be focusable through keyboard focus switching (tab/shift+tab) you need to set the focus policy of the component to focus_local. The default is focus_refuse for custom components.

    I'm not sure why your func_filter_message doesn't work. It's been used in CL_ComboBox_Impl to filter out clicks going to the lineedit, so maybe a look at Sources\GUI\Components\combobox.cpp helps? (Maybe you connected it to the parent widgets func_filter_message instead of the transparent components?)

    Mouse events are always sent to the component that is under the mouse pointer, and is independent of focus. If the component doesn't process the message it will go to the parent. That given, I'm not sure you need to use func_filter_message in this case? If that transparent component however covers other sibling components and you want click through like behavior (message goes to sibling, not parent) you need to manually redirect the input message to the right component by i.e. using get_component_at(event.mouse_pos) and message.set_target and then use send_message or then manually calling on_process_message of the target sibling. That's a bit of a hack though - what exactly are you trying to do?

  3. #3
    Lesser Knight
    Join Date
    Sep 2006
    Location
    Barcelona, Catalonia
    Posts
    30

    Default

    Hi Harry, thanks for the clear answer, the description you've attached is really useful and I haven't checked this one before.
    About the mouse question, I have a window with two different components, that are children of a common general parent. On top of these two components I want to paint an image used as a frame on top of the window. I've tried to render this image inside the "on_render" method of the parent, but as it is called before painting the children it doesn't work, so I've created a CL_Frame with the image as a background...this works, but the CL_Frame is receiving all the mouse input instead of the two real components under him.

    I will take a look to the examples you have mentioned, thank you!

    Xavi

    Quote Originally Posted by Harry View Post
    Yes, keyboard input goes to the focused widget. If the focused widget doesn't consume the message, the message is sent up to the parent components and finally the gui managers dialog input handling routines and the accelerator table. There's a detailed (and accurate) description here: http://clanlib.org/docs/clanlib-2.0....i_details.html)

    No component gets focus automatically. If you want a component to be focused at application startup you should call set_focus() on it manually. For components that get focused when you click them you should handle that in the components message handler. For instance CL_LineEdit calls CL_GUIComponent::set_focus() in the mouse click handler. If you want custom components to be focusable through keyboard focus switching (tab/shift+tab) you need to set the focus policy of the component to focus_local. The default is focus_refuse for custom components.

    I'm not sure why your func_filter_message doesn't work. It's been used in CL_ComboBox_Impl to filter out clicks going to the lineedit, so maybe a look at Sources\GUI\Components\combobox.cpp helps? (Maybe you connected it to the parent widgets func_filter_message instead of the transparent components?)

    Mouse events are always sent to the component that is under the mouse pointer, and is independent of focus. If the component doesn't process the message it will go to the parent. That given, I'm not sure you need to use func_filter_message in this case? If that transparent component however covers other sibling components and you want click through like behavior (message goes to sibling, not parent) you need to manually redirect the input message to the right component by i.e. using get_component_at(event.mouse_pos) and message.set_target and then use send_message or then manually calling on_process_message of the target sibling. That's a bit of a hack though - what exactly are you trying to do?

  4. #4
    Lesser Knight
    Join Date
    Sep 2006
    Location
    Barcelona, Catalonia
    Posts
    30

    Default

    Effectively I had not connected the correct func_filter_message . now everything works fine, thank you!

  5. #5
    ClanLib Developer
    Join Date
    May 2007
    Posts
    1,824

    Default

    Quote: "CL_Frame is receiving all the mouse input instead of the two real components under him"

    Under a different situation, I also had that a while ago. If I had a CL_PushButton as a child of CL_Frame, it did not receive any input.

    I am not sure if it has been fixed.

    (Instead, I simply made the CL_Frame not have any children, so CL_PushButton is processed before CL_Frame)

  6. #6
    Lesser Knight
    Join Date
    Sep 2006
    Location
    Barcelona, Catalonia
    Posts
    30

    Default

    Just a note in case of other people using filter_message for mouse input...make sure that you are translating the coords of the mouse position from the filtered component to window, and from there to the new component obtained via "get_component_at".
    If you don't make this translation you will get mad wondering why the other components get the mouse pos wrong, I can assure you

    Xavi

  7. #7
    Lesser Knight
    Join Date
    Sep 2006
    Location
    Barcelona, Catalonia
    Posts
    30

    Default

    Hi, I've seen that send_message method has been removed from CL_GUIComponent, so how can I use func_filter to send the message to one of the component children? I'm trying to check the examples but none of them tries to make a similar functionality...

    Thanks!

  8. #8
    ClanLib Developer
    Join Date
    May 2007
    Posts
    1,824

    Default

    I believe that messaging in general is currently being looked at ... so it's a bit transitional in svn at the moment

  9. #9
    Lesser Knight
    Join Date
    Sep 2006
    Location
    Barcelona, Catalonia
    Posts
    30

    Default

    Quote Originally Posted by rombust View Post
    I believe that messaging in general is currently being looked at ... so it's a bit transitional in svn at the moment
    Thanks Rombust, I've changed my code to use "process_message" by now...are you thinking about changing the message system of gui components?

    Xavi

  10. #10
    ClanLib Developer
    Join Date
    May 2007
    Posts
    1,824

    Default

    I'm personally not at the moment, I haven't much spare time.

    It has been talked about on IRC ( http://webchat.freenode.net/?channels=clanlib ). I am not sure of the details, but the intention is to move CL_DisplayMessageQueue out of ClanDisplay and into ClanCore, with hooks for the WIN32 target for the "PeekMessage/TranslateMessage/DispatchMessage" stuff in ClanDisplay (Not required for Linux, except the SDL target would also need to use the hook). And a better system for messaging with the GUI

  11. #11
    ClanLib Developer
    Join Date
    Sep 2006
    Location
    Bergen, Norway
    Posts
    588

    Default

    I just asked around for this on the irc channel, and got the following reply:

    "I may have killed that send_message function as part of the msg queue clean up. My advice would be not to use send_message, but if he absolutely must do that, he can still do it by using dispatch_message() on CL_GUIManager"

  12. #12
    Lesser Knight
    Join Date
    Sep 2006
    Location
    Barcelona, Catalonia
    Posts
    30

    Default

    Thank you for the replies. I fixed the problem calling directly to the input callbacks of the other components, thus controlling which messages are sent to the component children...now it works fine.

    Xavi

Similar Threads

  1. Replies: 1
    Last Post: 04-13-2009, 03:19 AM
  2. Blocking keyboard input
    By Anvilfolk in forum Official ClanLib SDK Forums
    Replies: 2
    Last Post: 09-14-2007, 10:21 AM
  3. Mouse Input not caught always
    By gmatt in forum Official ClanLib SDK Forums
    Replies: 2
    Last Post: 06-26-2007, 11:13 PM
  4. Mouse Input
    By Soudeus in forum Official ClanLib SDK Forums
    Replies: 2
    Last Post: 04-25-2007, 01:57 PM
  5. keyboard controlls??
    By Gexy in forum Funeral Quest
    Replies: 3
    Last Post: 01-31-2006, 05:36 PM

Bookmarks

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •