Drag and drop doesn't respond to every second mouse click

Create issue
Issue #181 resolved
Former user created an issue

Automatic migration. Original reporter: "Jabberwocky"

I believe this bug fix inadvertently caused a problem with drag and drop in 0.6.0:

"Bug Fix: Any window responding to a left mouse button down event would always report the event as 'unhandled' even though it may have taken action based on the event (thus, handling it). Event is now marked as 'handled' if, but only if, the window has to take action such as activating the window or making a change in the z-order. (http://www.cegui.org.uk/mantis/view.php?id=136)"

The problem: Every second click on my DragDropTarget is ignored.

I have an inventory-style screen which allows the user to drag around icons from one slot to another. With the upgrade to 0.6.0, the user must now click on an icon twice in order to move it. The first click is completely ignored.

Diagnosis:

- Inside System::injectMouseButtonDown (ceguisystem.cpp) we loop through all the target windows for a mouse click. - The loop continues until the event is marked as handled - Every second click results in activation of a new window, which causes the event to be marked as handled. - This causes the loop to terminate before DragContainer::onMouseButtonDown is called. - The next time the user clicks the same icon, there is no change in window activation, and DragContainer::onMouseButtonDown is properly called.

Reproducibility: always

Comments (5)

  1. Paul Turner

    I'm kind of working on this at the moment.

    What is the 'content' of the DragContainer? Is it a StaticImage? If so you can set the MousePassThroughEnabled property on the StaticImage to True and it should then work correctly.

    If you're wondering why the work-around, it's because I am considering a change to the general behavior of the inputs...

    I'm not particularly happy about the way that the events get recursively passed back up the hierarchy; it causes a lot of issues, especially with regards to consistency issues (like this one). I can't recall what the reasoning was behind this recursion; it was not like this in the Mk-1 system, but has always been this way in the Mk-2 system - i.e. it was not added afterwards, so not log message telling me why it was added ;)

  2. Former user Account Deleted

    Original reporter: Jabberwocky

    Sorry for the slow reply. I forgot to monitor this bug.

    Yep - I'm using a StaticImage for the DragContainer content. Adding MousePassThroughEnabled totally does the trick.

    Thanks for the note on event recursion. I'm not familiar enough with the guts of CEGUI to offer much interesting feedback. But needing to set the MousePassThroughEnabled property on the DragContainer contents doesn't seem hacky in any way, so long as a person knows this is necessary.

  3. Paul Turner

    Good to know the MousePassThroughEnabled setting has worked.

    As far as the events getting passed back up the hierarchy, I intend to remove this behaviour as the default - tests have shown that aside from a couple of internal items to be fixed up, in general things otherwise proceed as normal.

    So, I'm leaning towards implementing the change as an option; for 0.6.1+ releases, it will be enabled so behaviour is the same as it is now. For 0.7 and upwards, the new behaviour would be the default.

    The only other PITA is return values from the event injection functions, and a generally accepted use (whereby if CEGUI returns false, you use the input in your game/app) - this is already broken as of 0.6.0, I just need a half-decent solution or 'best practice' for people to use.

    I think all of this 'other stuff' relating to events is more for a new ticket :)

  4. Paul Turner

    Marking as resolved due to the use of the accepted work-around. The larger issue of recursive propagation of events (or not) is still to be addressed, but is not what this ticket was really about.

  5. Log in to comment