Mouse Button down and dragging.

[HexDump]

Hi all,

I need to model this behaviour:

1) User clicks on a grid -> a squared is painted
2) User drags the mouse -> more squared are painted as it moves.

I have been checking events but did not find any about mouse dragging, how can I accomplish this?.

HexDump.

[CrazyEddie]

Hi,

CEGUI does not differentiate "dragging" from normal mouse movement; this is something you will have to track yourself.

Basically, have handlers for mouse button down and mouse button up events on all the squares, and in those handlers you can maintain a button down/up state. Then within a handler (maybe for mouse enters) you can inspect the state of the button flag and paint the square (or not) as appropriate.

HTH

CE.

[HexDump]

Yes, this was my second option .

Just another question, I have a frame window that covers part of a "default window". For the dragging thing I have defined for the "default window" a mousedown/mouseup event. I was surprised when I noticed that when pressed mouse button on the frame window the "mousedown" event of the "default window" was called wich is below the frame. What's hapenning? Shouldn´t this event die because the frame window is not handling it?

By the way, I have done some other tests, click event works the way I stated before. If I press on the framewindow, it is not passed to the default window. Perhaps the problem is that when producing an event on a window if it is hasn´t handler for the event it continues traveling to the parent or window below?

Thanks in advance,
HexDump.

[CrazyEddie]

I was surprised when I noticed that when pressed mouse button on the frame window the "mousedown" event of the "default window" was called wich is below the frame. What's hapenning? Shouldn´t this event die because the frame window is not handling it?

The fact that the FrameWindow does nothing in response to this is the reason it gets sent to the next window up in the hierarchy.

To explain a bit more - say you had two sibling frame windows, if you clicked on the inactive one, the frame window would react to activate the window and consume the event. If the window is already active, it does nothing so the event is not consumed. The more I think about it, the more the whole situation seems absurd.

Perhaps the problem is that when producing an event on a window if it is hasn´t handler for the event it continues traveling to the parent or window below?

That is largely the situation at the moment, yes.

CE