Bug in REPEAT + WAIT(-1) when [UNTIL 0;] (FW 11226)

[Carlos295pz]

These commands work poorly by working this way, recognizes an extra menu tap

Code:

EXPORT Bug_REPEAT_WAIT()
BEGIN

 LOCAL Action,Cnt;

 RECT;
 TEXTOUT_P("Touch the screen",50,120);
 0▶Action;

 REPEAT
  WAIT(-1)▶Action;
  IF TYPE(Action) THEN
   Cnt+1▶Cnt;
   IF Action(1)=3 THEN
    RECT;
    TEXTOUT_P("Number of Screen Events: "+Cnt,50,120)
   END
  END
 UNTIL 0;

END;

[Carlos295pz]

When touching the screen (outside the menu area), you should only register 2 events, however it registers 3, being a menu touch (lower bar) added.

[Han]

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.

[Tim Wessman]

You might want to take an action on the touch down, on the touch up, or when a "touch click" was completed....

There are also move events, and long-hold events.

Try dragging your finger and take a look how many events you will register.

Do you still think there is a bug here or are things clear now?

[Carlos295pz]

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);

 REPEAT

  Action:=WAIT(−1);

  RECT_P(125,100);
  Cnt:=Cnt+1;
  TEXTOUT_P(Action,125,100,2);
  TEXTOUT_P(Cnt,125,115,2);

 UNTIL ISKEYDOWN(4);

END;

[Carlos295pz]

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.

[Carlos295pz]

(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.

[Tim Wessman]

It is not an error and is the expected behavior.

[Carlos295pz]

(02-07-2017 09:31 PM)Tim Wessman Wrote:  It is not an error and is the expected behavior.

Why in the video example only 2 events are shown? And not 3 as in the main thread code.

[Han]

(02-08-2017 02:56 AM)Carlos295pz Wrote:  

(02-07-2017 09:31 PM)Tim Wessman Wrote:  It is not an error and is the expected behavior.

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.

[Carlos295pz]

[Carlos295pz]

(02-08-2017 03:52 AM)Han Wrote:  

(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: ?

With ISKEYDOWN:
0: New
2: Completed
3: ?
4:

Result not coincident with what was shown.

[Carlos295pz]

I doubt it is due to times, I think it is more a language error, probably with ISKEYDOWN, I still think that a third event should not be registered.

This code gives a space of time between each WAIT (-1), it registers 3 events:

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);

 REPEAT

  Action:=WAIT(−1);

  RECT_P(125,100);
  Cnt:=Cnt+1;
  TEXTOUT_P(Action,125,100,2);
  TEXTOUT_P(Cnt,125,115,2);

 UNTIL 0*WAIT(1.005);

END;

[cyrille de brébisson]

Hello,

(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!

Cyrille

[Carlos295pz]

(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.

(02-08-2017 04:07 AM)Carlos295pz Wrote:  

[cyrille de brébisson]

Hello,

yes, it is. 3 is click and if you do a mouse down, then up, then a click is also generated.

Cyrille