SimpleWindow.eventLoop

The event loop automatically returns when the window is closed pulseTimeout is given in milliseconds. If pulseTimeout == 0, no pulse timer is created. The event loop will block until an event arrives or the pulse timer goes off.

The given eventHandlers are passed to setEventHandlers, which in turn assigns them to handleKeyEvent, handleCharEvent, handlePulse, and handleMouseEvent, based on the signature of delegates you provide.

Give one with no parameters to set a timer pulse handler. Give one that takes KeyEvent for a key handler, MouseEvent, for a mouse handler, and one that takes dchar for a char event handler. You can use as many or as few handlers as you need for your application.

  1. int eventLoop(long pulseTimeout, T eventHandlers)
  2. int eventLoop(T eventHandlers)
    class SimpleWindow
    final
    int
    eventLoop
    (
    T...
    )
    if (
    T.length == 0 ||
    is(T[0] == delegate)
    )

Bugs

You should always have one event loop live for your application. If you make two windows in sequence, the second call to eventLoop might fail:
// don't do this!
auto window = new SimpleWindow();
window.eventLoop(0);

auto window2 = new SimpleWindow();
window2.eventLoop(0); // problematic! might crash

simpledisplay's current implementation assumes that final cleanup is done when the event loop refcount reaches zero. So after the first eventLoop returns, when there isn't already another one active, it assumes the program will exit soon and cleans up.

This is arguably a bug that it doesn't reinitialize, and I'll probably change it eventually, but in the mean time, there's an easy solution:

// do this
EventLoop mainEventLoop = EventLoop.get; // just add this line

auto window = new SimpleWindow();
window.eventLoop(0);

auto window2 = new SimpleWindow();
window2.eventLoop(0); // perfectly fine since mainEventLoop still alive

By adding a top-level reference to the event loop, it ensures the final cleanup is not performed until it goes out of scope too, letting the individual window loops work without trouble despite the bug.

See Also

Meta

History

The overload without pulseTimeout was added on December 8, 2021.

On December 9, 2021, the default blocking mode (which is now configurable because eventLoopWithBlockingMode was added) switched from BlockingMode.untilApplicationQuits over to BlockingMode.automatic. This should almost never be noticeable to you since the typical simpledisplay paradigm has been (and I still recommend) to have one eventLoop call.