Many widgets can respond to events. There are many basic events: mouse, keyboard, paint, etc. Not all widgets respond to every event and the events are divided in seperate classes, like Reactive and Commanding.

Events are parametrised by the widget that responds to this event and the type of their event handler. For example, the activate event has type:

 activate :: Form w => Event w (IO ())

This means that all widgets in the Form class can respond to the activate event with an IO action. The mouse event handler takes a MouseEvent as an argument and has type:

 mouse :: Reactive w => Event w (MouseEvent -> IO ())

A specific event handler can be set or read with the on function. For example:

 do w <- window [title =: "passive"]
    set w [on activate   =: set w [title =: "active"]]
    set w [on deactivate =: set w [title =: "deactive"]]

For convenience, the mouse and keyboard events have a serie of event filters, click, motion, enterKey, charKey, etc. These filters are write-only attributes but many can be active at the same time. However, all filters will be overwritten again if the basic event handler mouse or keyboard is set again. For example, the following program makes sense:

 window [on mouse =: ..., on click =: ..., on motion =: ...]

But in the following program, only the handler for mouse will be called (*):

 window [on clickRight =: ..., on drag =: ..., on mouse =: ...]

(*) If you want to set the mouse later but want to retain the old event filters, you can first read the current mouse handler and call that explicitly in the new event handler (and the same for the keyboard of course). This also the implementation technique used for the event filters themselves.

 do w <- window [on click =: ..., on motion =: ...]
    prev <- get w (on mouse)
    set w [on mouse =: \m -> do{ prev m; ... }]