Results 1 to 5 of 5

Thread: MouseArea:weird behavior (mechanism) of onPressed

  1. #1
    Join Date
    Sep 2015
    Posts
    12
    Thanks
    4
    Qt products
    Qt5
    Platforms
    MacOS X Windows Android

    Default MouseArea:weird behavior (mechanism) of onPressed

    Hi all,

    For some reason, I need to propagate "Pressed event" to lower MouseArea. In the meanwhile, I still want to handle "Clicked event" after handling "Pressed event".
    It turns out that I cannot achieve both criteria together.

    If I set mouse.accepted = false during handling redBlock's onPressed() as example code below, I can successfully propagate "Pressed event" to blueBlock. However, this will disable the handling of "Clicked event" in redBlock which I don't think it makes any sense.

    From QT document,
    pressed(MouseEvent mouse):
    When handling this signal, use the accepted property of the mouse parameter to control whether this MouseArea handles the press and all future mouse events until release.The default is to accept the event and not allow other MouseAreas beneath this one to handle the event. If accepted is set to false, no further events will be sent to this MouseArea until the button is next pressed.

    I don't understand why they design like this. "If accepted is set to false, no further events will be sent to this MouseArea until the button is next pressed." doesn't make any sense to me. When you set mouse.accepted = false, you expect that the other mouse handler can take over this mouse event. Does anyone know why they design such weird mechanism for onPressed?

    Qt Code:
    1. import QtQuick 2.4
    2. import QtQuick.Controls 1.3
    3. import QtQuick.Window 2.2
    4.  
    5. ApplicationWindow {
    6. title: qsTr("Hello World")
    7. width: 1280
    8. height: 720
    9. visible: true
    10.  
    11. Rectangle{
    12. id: blueBlock
    13. width: parent.width ; height: parent.height;
    14. color: "blue"
    15. MouseArea{
    16. anchors.fill: parent
    17. onPressed:{
    18. console.log("Blue block is pressed")
    19. }
    20. onClicked: {
    21. console.log("Blue block is clicked")
    22. }
    23. }
    24. }
    25. Rectangle{
    26. id: redBlock
    27. width: parent.width/2; height: parent.height/2
    28. anchors.centerIn: parent
    29. color: "red"
    30. MouseArea{
    31. anchors.fill: parent
    32. onPressed:{
    33. console.log("Red block is pressed")
    34. mouse.accepted = false
    35. }
    36. onClicked: {
    37. console.log("Red block is clicked")
    38. }
    39.  
    40. }
    41. }
    42. }
    To copy to clipboard, switch view to plain text mode 

  2. #2
    Join Date
    Jan 2006
    Location
    Graz, Austria
    Posts
    8,416
    Thanks
    37
    Thanked 1,544 Times in 1,494 Posts
    Qt products
    Qt3 Qt4 Qt5
    Platforms
    Unix/X11 Windows

    Default Re: MouseArea:weird behavior (mechanism) of onPressed

    If you only need the click in redBlock, maybe put that mouse are under the other and let the other propagate composed events?

    Cheers,
    _

  3. #3
    Join Date
    Sep 2015
    Posts
    12
    Thanks
    4
    Qt products
    Qt5
    Platforms
    MacOS X Windows Android

    Default Re: MouseArea:weird behavior (mechanism) of onPressed

    Hi Anda_Skoa,
    Thanks. But what I need for redBlock is both "press" and "click".

    The reason is a little bit long. But I am willing to tell you if you think that will help you to answer my question.

  4. #4
    Join Date
    Jan 2006
    Location
    Graz, Austria
    Posts
    8,416
    Thanks
    37
    Thanked 1,544 Times in 1,494 Posts
    Qt products
    Qt3 Qt4 Qt5
    Platforms
    Unix/X11 Windows

    Default Re: MouseArea:weird behavior (mechanism) of onPressed

    Hmm.

    What if you don't let the redBlock MouseArea "ignore" the event but let its handlers just invoke both targets?

    E.g. if a click on redBlock should trigger that MouseArea's onClicked and that of blueBlock, just call both target functions in redBlock?

    Cheers,
    _

  5. The following user says thank you to anda_skoa for this useful post:

    clarksuper0420 (3rd September 2015)

  6. #5
    Join Date
    Sep 2015
    Posts
    12
    Thanks
    4
    Qt products
    Qt5
    Platforms
    MacOS X Windows Android

    Default Re: MouseArea:weird behavior (mechanism) of onPressed

    Actually, I cannot call blueBlock's pressed & clicked handler in redBlock because in my case, redBlock is larger than blueBlock. Clicking redBlock doesn't guarantee that the blueBlock should be clicked.
    In order to explain this problem well, I need to refer my other post: http://www.qtcentre.org/threads/6358...rk-in-ListView

    My redBlock is ListView which has higher priority to receive mouse event. And moreover, it has larger area than its items. That means when I clicked ListView (redBlock), that doesn't guarantee blueBlock (items) must be clicked. I use Rectangle red & blue block to illustrate my question in this post so I can simplify my question. Which is unreasonable design of "If accepted is set to false, no further events will be sent to this MouseArea until the button is next pressed.".

    I was trying to solve my problem by following ideas.
    1. ListView get onPressed first. Set mouse.accepted = false so item's onPressed can be triggered.
    2. Item's onPressed set a flag, called isHandlingItem, to true.
    3. When ListView's onClicked get mouse event first. It can use the flag to know whether it should handle it or not
    However, the ListView won't be able to receive onClicked because mouse.accepted = false will weirdly disable the other mouse event.

    Anyway, this whole problem shouldn't be such complex if I can reserve the mouse priority between ListView and its items. And you helped me with that already. So I don't have to use onPressed to work around. So this onPressed problem is not critical anymore.

    However. Still, I think the design of "If accepted is set to false, no further events will be sent to this MouseArea until the button is next pressed." doesn't fit instinct (or fit other mouseArea logic). So I was wondering if I understand it wrong or it is what it is.


    I tried my best to explain the whole story well but I know it's not easy to understand it by reading my expression. Thank you very much for your time. I appreciate your kindly help.

Similar Threads

  1. Weird setStyleSheet() behavior in Qt 5.3
    By Carlsberg in forum Qt Programming
    Replies: 0
    Last Post: 10th June 2014, 16:00
  2. mouseArea hover behavior interferes with tooltips
    By schnitzel in forum Qt Quick
    Replies: 0
    Last Post: 23rd February 2014, 20:36
  3. Replies: 1
    Last Post: 24th October 2011, 14:49
  4. Weird removeRow behavior
    By metalinspired in forum Qt Programming
    Replies: 0
    Last Post: 30th August 2009, 12:42
  5. Weird QMenu behavior on Mac
    By munna in forum Qt Programming
    Replies: 1
    Last Post: 14th January 2009, 15:18

Tags for this Thread

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
  •  
Digia, Qt and their respective logos are trademarks of Digia Plc in Finland and/or other countries worldwide.