[View] `do-events/no-wait` processes only ONE event

Open
#4,206 41 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
3/5
Estimated time
1-2 days
Newbie friendliness
45/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Stale
Domain
desktop, operating-systems

Research direction

Start in modules/view/backends/windows/events.reds around the do-events/no-wait implementation at the referenced line, and compare it with the older version linked in the issue. Reproduce the behavior with the supplied view example on Windows. Done means one call processes all queued window messages before returning, rather than only one event.

Written by the indexing model from the issue text.

Description

type.review

Describe the bug

I would expect do-events/no-wait to process all queued events before returning, but it processes only one event (likely a leftover from the 2015 version of it). Otherwise I have to call it in a loop a lot of times to be sure.

To reproduce

I'm running mouse click simulations, but here's a silly example:

view [
	b: base on-down [n: n + 1]
	button "hit me" [
		n: 0
		b/color: red
		loop 10 [do-events/no-wait]	;) multiple calls only to force it to renew b/color
		wait 3
		b/color: gray
		loop 10 [do-events/no-wait]
		print [n 'presses 'detected]
	]
]
  1. Click the button, observe the base turning red
  2. Click the base many times during 3 seconds (until it becomes gray again)
  3. Observe the message in the console: 10 calls to do-events can detect up to 4 clicks (other 4 times are likely wasted on on-up events, another 2 on b/color)

Expected behavior

A single call to do-events/no-wait empties the window message queue.

Platform version (please complete the following information)

Red 0.6.4 for Windows built 20-Dec-2019/19:03:46+03:00 commit #544a6e1
Dominant language
Red
Stars
6k
Forks
416
No merged PRs in 30d

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from red/red

All issues in red/red

Similar issues

More Desktop Dev issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.