MOUSE() Event Strange Behaviour

[Freire]

Well, I'm trying to implement the Long Click Event to some functions on the Virtual Keys
Due to some functions being called over time, I have to call for MOUSE() function instead of WAIT(-1) in order to catch mouse interaction.
While WAIT(-1) successfully gives me back when long clicks occur (Although I already understood the reason why it behaves a bit unusual>
Bug in REPEAT + WAIT(-1) when UNTIL 0;), the MOUSE() function is failing to give it back to me.
From help:

Quote:MOUSE[(index)]
Returns two lists describing the current location of each potential pointer (or empty lists if the pointers are not used). The output is {x , y, original z, original y, type} where type is 0 (for new), 1 (for completed), 2 (for drag), 3 (for stretch), 4 (for rotate), and 5 (for long click).
The optional parameter index is the nth element that would have been returned—x, y, original x, etc.—had the parameter been omitted (or –1 if no pointer activity had occurred).

So I was expecting MOUSE(4) to Return -1,0,1,2,5 for a single finger iteration, but I was not able to reproduce the Return of 5, and apparently I'm receiving 1 only when using the SOFTMENU area.
Also I noticed a MOUSE(4) returning number 7:
Put two fingers, stretch, then release one finger. Not 100% chance, but very high chance of giving number 7 out of MOUSE(4).
Code to test these: [Things that were commented out have also all been tested, give it a try.]

Code:

// ===========================================================================​========================
// Author:              F. Freire
// Name:                Test_Mouse
// Create date:         16 June 2017
// Firmware Target:     10637 -> 29/08/2016
// ===========================================================================​========================
EXPORT Test_Mouse()
BEGIN
    LOCAL waitlist;
    LOCAL bg:=RGB(0,0,0);
    LOCAL fg:=RGB(255,255,255);
    LOCAL mouse_event;
    LOCAL mode_list:={"Completed","Drag","Stretch","Rotate","Long Click","New"};
    RECT_P();
    TEXTOUT_P("GETMOUSE Testing",100,10,3,bg,320,fg);
    TEXTOUT_P("GetMouse Px:",20,50,3,bg,320,fg);
    TEXTOUT_P("MOUSE(0) [x]:",20,70,3,bg,320,fg);
    TEXTOUT_P("MOUSE(1) [y]:",20,90,3,bg,320,fg);
    TEXTOUT_P("MOUSE(2) [x0]:",20,110,3,bg,320,fg);
    TEXTOUT_P("MOUSE(3) [y0]:",20,130,3,bg,320,fg);
    TEXTOUT_P("MOUSE(4) []:",20,150,3,bg,320,fg);
    TEXTOUT_P("Touch Mode:",20,170,3,bg,320,fg);
    //WHILE 1 DO
    REPEAT
        //WAIT(-1); // Testing With Wait
        IF MOUSE(4)<>-1 THEN
            IFERR
                RECT_P(G0,130,50,320,190);
                mouse_event:=B→R(MOUSE());
                TEXTOUT_P(mouse_event,G0,130,50,3,bg,320,fg);
                //TEXTOUT_P(B→R(MOUSE(0)),130,70,3,bg,320,fg);
                //TEXTOUT_P(B→R(MOUSE(1)),130,90,3,bg,320,fg);
                //TEXTOUT_P(B→R(MOUSE(2)),130,110,3,bg,320,fg);
                //TEXTOUT_P(B→R(MOUSE(3)),130,130,3,bg,320,fg);
                //TEXTOUT_P(B→R(MOUSE(4)),130,150,3,bg,320,fg);
                //TEXTOUT_P(mode_list(B→R(MOUSE(4))),130,170,3,bg,320,fg);
                TEXTOUT_P(mouse_event(1,1),130,70,3,bg,320,fg);
                TEXTOUT_P(mouse_event(1,2),130,90,3,bg,320,fg);
                TEXTOUT_P(mouse_event(1,3),130,110,3,bg,320,fg);
                TEXTOUT_P(mouse_event(1,4),130,130,3,bg,320,fg);
                TEXTOUT_P(mouse_event(1,5),130,150,3,bg,320,fg);
                TEXTOUT_P(mode_list(mouse_event(1,5)),130,170,3,bg,320,fg);
            THEN
                //WAIT(0.1);
            END;
        END;
        //WAIT(0.1); // Too fast?
    //END; // End While
    UNTIL 0; // End Repeat Test1
    //UNTIL ISKEYDOWN(4); // End Repeat Test2
END;

[Freire]

No ideas?

[Freire]

Up. Since there is a new firmware around, can someone check this?
Thanks.

[cyrille de brébisson]

Hello,

Sorry, but I have not looked at the full program and might be answering only partially the question here...

But here is some tidbit of information.

The screen is like a windowing system, with the menu being one window and the main part of the screen another (that is unless you are in another more complicated UI such as a choose box where you have extra windows on top of these main windows...)

MOUSE events get sent to the appropriate window for processing (the one under the mouse)...

Now, windows, such a the menu, do not, and have no interest in any gestures, all it cares about is click/touch event.
So, in order to speed up the response to mouse down on the menu, this specific window is marked as: Does not accept gestures. This causes the mouse processing system to send a click message as soon as a down finger is detected on the menu and then discard anything else...

Although this is a nice feature that saves battery power and makes the calculator more responsive, there is a side effect...

When you use MOUSE in program (which looks for mouse events in the various windows queues), it will get mouses messages that have already passed through that filter. So if you press in the menu area, you get different behaviors than if you press in other area of the screen.

Hope this helps.
Cyrille

[Freire]

I perfectly understand the different behaviour in menu area, and I agree to the behaviour.
The problem is I don't have normal behaviour in the common area.(The rest of the screen outside of menu area.)
As stated before, MOUSE(4) doesn't return long clicks or two fingers interactions, although it returns a 7 as described.