Programming mouse or keyboard events handlers using Lwt
Reminder: Event capturing starts with the outer most element in the DOM and works inwards to the HTML element the event took place on (capture phase) and then out again (bubbling phase).
make_event ev target creates a Lwt thread that waits
for the event ev to happen on target (once).
This thread is cancellable using
TARGET NONE: <<a_api project="lwt" | val Lwt.cancel>>.
If you set the optional parameter ~use_capture:true,
the event will be caught during the capture phase,
otherwise it is caught during the bubbling phase
(default).
seq_loop (make_event ev) target handler creates a looping Lwt
thread that waits for the event ev to happen on target, then
execute handler, and start again waiting for the event. Events
happening during the execution of the handler are ignored. See
async_loop and buffered_loop for alternative semantics.
For example, the clicks function below is defined by:
let clicks ?use_capture t = seq_loop click ?use_capture t
The thread returned is cancellable using TARGET NONE: <<a_api project="lwt" | val Lwt.cancel>>. In order for the loop thread to be canceled from within the handler, the latter receives the former as its second parameter.
By default, cancelling the loop will not cancel the potential
currently running handler. This behaviour can be changed by
setting the cancel_handler parameter to true.
async_loop is similar to seq_loop, but each handler runs
independently. No event is thus missed, but since several
instances of the handler can be run concurrently, it is up to the
programmer to ensure that they interact correctly.
Cancelling the loop will not cancel the potential currently running handlers.
buffered_loop is similar to seq_loop, but any event that
occurs during an execution of the handler is queued instead of
being ingnored.
No event is thus missed, but there can be a non predictible delay between its trigger and its treatment. It is thus a good idea to use this loop with handlers whose running time is short, so the memorized event still makes sense when the handler is eventually executed. It is also up to the programmer to ensure that event handlers terminate so the queue will eventually be emptied.
By default, cancelling the loop will not cancel the (potential)
currently running handler, but any other queued event will be
dropped. This behaviour can be customized using the two optional
parameters cancel_handler and cancel_queue.
async t records a thread to be executed later.
It is implemented by calling yield, then Lwt.async.
This is useful if you want to create a new event listener
when you are inside an event handler.
This avoids the current event to be catched by the new event handler
(if it propagates).
func_limited_loop event delay_fun target handler will behave like
Lwt_js_events.async_loop event target handler but it will run delay_fun
first, and execut handler only when delay_fun is finished and
no other event occurred in the meantime.
This allows to limit the number of events catched.
Be careful, it is an asynchrone loop, so if you give too little time, several instances of your handler could be run in same time *