CursorListener vs MouseListener, when to use each? do they cope?

do you think we could have a Button.ButtonCursorHandler beyond the existing ButtonMouseHandler? as I ended giving up on using the already implemented Button.addClickCommands() because it ends in the hands of the ButtonMouseHandler.

while in debug, I am quite sure I saw the same mouse click generating different event objects: one for CursorListener and another for MouseListener.
I mean, they wont cope in a sense that the setConsumed() wont apply from one to the other, right?

so, should I use only CursorListener (and not MouseListener) in my whole application about things related to Lemur? I mean, I should avoid using both together?

or did I made some confusion (again)? :slight_smile:

so basically, while using only CursorListener, I managed to click or drag successfully (I just had to stop using Button.addClickCommands()). The same button is used to click (of course) and to drag its parentest panel.

When you add multiple mouse listeners to a spatial then they will all be called regardless of whether one sets consumed or not. When I added cursor listeners, I made them behave as if they were in that same list.

When adding multiple listeners to a spatial, the idea is that you know what you’re doing and that the listeners may coordinate among themselves. Else you have other kinds of issues.

…but your own listeners can check for isConsumed() when you are adding multiple listeners to the same spatial. If I didn’t send them the event then they couldn’t do anything at all. (One way you have options, the other you don’t.)

Note that mouse listeners always get called before cursor listeners, as I recall.

1 Like

I got this output from the test I made (one click on the button):

MouseButton(BTN=0, PRESSED)

CursorButtonEvent[buttonIndex=0, pressed=true, x=317.0, y=287.0, target=com.simsilica.lemur.Button[text=test, color=Colo
r[0.8, 0.9, 1.0, 0.85], elementId=ElementId[button]], view=com.jme3.renderer.ViewPort@38f8b946, collision=null]

MouseButton(BTN=0, RELEASED)

CursorButtonEvent[buttonIndex=0, pressed=false, x=503.0, y=284.0, target=null, view=null, collision=null]

so basically the mouse listener has a pre-consumed event, while the cursor listener let us use that boolean to control something. I think I get it now, thx!

Something seems broken. I will look into it soon. If I don’t respond in a few days then please remind me.

1 Like

By the way, if you feel particularly industrious, entering issues in the issue tracker on github will help me keep from forgetting these and will provide a nice tracing of the work done and whatever (assuming I remember to include the issue number in my commits. :))

1 Like

I am currently absorbing all the click commands of buttons, whenever they are assined to a new CursorListener that I created.

Absorbing because I remove from them, store on a userdata and execute the click commands thru that new CursorListener under specific conditions: it wont execute the “click” commands if the same button is being already dragged.

It is working great. I think the absorption (thru removal) is ok, but… I am just not sure, in a sense that what could it break, despite nothing looks broken til now after many runs on about a week.

EDIT: the click commands absorption central is working, for every CusorListener I create, when I addClickCommands() I just let the central absorb them and properly use the preferred behavios basedon isConsumed().