The three events are: mouse down, mouse up, and mouse click. These seem like normal events to return for screen touches that are not related to the menu.
I think this explains better, WAIT (-1) returns these types of events:
0: Initial pulse (New)
1: Drag
2: End of pulse
3: Pulse in menu area
5: Zoom
6: Rotate
7: Long Pulse
Let's see what should happen:
For a normal touch only 2 pulses should be counted as seen in this example:
Code:
EXPORT REPEAT_WAIT()
BEGIN
LOCAL Action,Cnt;
RECT;
TEXTOUT_P("Touch the screen",15,70,5);
TEXTOUT_P("WAIT(-1) value: --",20,100,2);
TEXTOUT_P("Number of Events: --",20,115,2);
(02-03-2017 08:59 PM)Han Wrote: [ -> ]The three events are: mouse down, mouse up, and mouse click. These seem like normal events to return for screen touches that are not related to the menu.
It may be similar to events defined in the PC languages, but I also think that in HP PPL only 2 events were chosen for this purpose.
In the previous code appears a third event, which belongs to a touch in the menu area, so I consider it is a language error, I want it to be the Cyrille of a comment about it to close my doubt.
(02-08-2017 02:56 AM)Carlos295pz Wrote: [ -> ]Why in the video example only 2 events are shown? And not 3 as in the main thread code.
Because you trapped the second event in the ISKEYDOWN() command. Change the UNTIL line to UNTIL 0; and you will see all three events.
Whether ISKEYDOWN() is supposed to "pop" the event buffer, I am not sure.
But does not the same happen with the long click, ISKEYDOWN () consumes may be spanning so long? it's strange.
It is understood that ISKEYDOWN will influence when running GETKEY in "simultaneous", but with WAIT (-1) it would not cause a lag of 1 event per loop? as:
0: New
2: Completed
3: ?
(02-04-2017 06:27 AM)Carlos295pz Wrote: [ -> ]The reported error is generated by pressing out of the menu area, a touch is added in the menu area, with 3 being the number of events instead of 2.
One of the thing that I do not like in lots of modern systems is the apparent slowness of them.
One of the reason for said slowness comes from the fact that the "click" events gets generated on "touch up", not "touch down" because after a "touch down", they do not know if you meant to click, swipe, long press or do something else...
So, one thing that I did to avoid this is to allow "windows" to declare themselves as "click only". Meaning that the only mouse event that they will handle is a a click. When a window is declared as such, then a click event is generated as soon as you do a touch down and the rest of the code is bypassed...
The "normal" screen has 1 main "window", the Desktop which takes the full screen.
In this window, you have 3 smaller windows: the command line, the "stack display" and the menu (at the bottom).
The menu does have the "click" only flag set.
When you create a user program, these windows are still there, present and any event pays attention to them...
This is why you see different events when you touch in the menu area than when you touch in the rest of the screen!
So, here you go, short question, log answer. I hope that it helps!
(02-08-2017 06:25 AM)cyrille de brébisson Wrote: [ -> ]Hello,
The "normal" screen has 1 main "window", the Desktop which takes the full screen.
In this window, you have 3 smaller windows: the command line, the "stack display" and the menu (at the bottom).
The menu does have the "click" only flag set.
When you create a user program, these windows are still there, present and any event pays attention to them...
This is why you see different events when you touch in the menu area than when you touch in the rest of the screen!
Cyrille
I have no problem with the results according to the zones. My question was whether it is correct or not, that a type 3 click is shown when playing outside the menu area.