Post Reply 
MOUSE() Event Strange Behaviour
06-16-2017, 03:58 PM (This post was last modified: 06-16-2017 03:58 PM by Freire.)
Post: #1
MOUSE() Event Strange Behaviour
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:
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.]
// ===========================================================================​========================
// Author:              F. Freire
// Name:                Test_Mouse
// Create date:         16 June 2017
// Firmware Target:     10637 -> 29/08/2016
// ===========================================================================​========================
EXPORT Test_Mouse()
    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"};
    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
        //WAIT(-1); // Testing With Wait
        IF MOUSE(4)<>-1 THEN
        //WAIT(0.1); // Too fast?
    //END; // End While
    UNTIL 0; // End Repeat Test1
    //UNTIL ISKEYDOWN(4); // End Repeat Test2

Attached File(s)
.hpprgm  Test_Mouse.hpprgm (Size: 5.56 KB / Downloads: 2)
Find all posts by this user
Quote this message in a reply
06-23-2017, 06:12 PM
Post: #2
RE: MOUSE() Event Strange Behaviour
No ideas?
Find all posts by this user
Quote this message in a reply
07-16-2017, 03:39 AM
Post: #3
RE: MOUSE() Event Strange Behaviour
Up. Since there is a new firmware around, can someone check this?
Find all posts by this user
Quote this message in a reply
07-17-2017, 01:42 PM
Post: #4
RE: MOUSE() Event Strange Behaviour

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.

Although I work for the HP calculator group, the views and opinions I post here are my own. I do not speak for HP.
Find all posts by this user
Quote this message in a reply
07-18-2017, 12:59 AM (This post was last modified: 07-18-2017 12:59 AM by Freire.)
Post: #5
RE: MOUSE() Event Strange Behaviour
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.
Find all posts by this user
Quote this message in a reply
Post Reply 

User(s) browsing this thread: 1 Guest(s)