用户只提供操作（按下按钮，在对话框中进行选择等）
这些操作 [有时]被底层框架转换为事件。从概念上讲，事件可以被理解为[通知]“消息”发送到方法，这些方法已隐式或显式地向底层框架“注册”以通知[针对特定类型的事件]。实际上，框架只是使用适当的参数调用这些方法，而这样的调用实际上是一个事件。
事件一词也用于指定特定类型的事件。例如，有人谈到给定编辑框或其他 UI 元素的“更改”事件或“提交”事件。从这个意义上说，事件不是调用底层方法的机会的特定实例，而是保证调用方法的通用条件集。
因此，用户实际上并没有像问题中所说的那样“提交消息”，他/她对各种 UI 元素采取了一些行动，而这些行动 [可能] 导致框架检测到特定事件类型（或多个）。然后框架查找当前注册了哪些方法来接收相应的通知，然后框架调用这些方法，传递适当的参数（构成供方法使用的各种“消息”）。
这个模型背后的主要思想是为应用层提供特定的逻辑来处理事件，而不用担心跟随系统和用户的每一个“动作”。该框架执行此操作，并且可以信任通知相关事件处理程序是否特定用户操作（或系统条件，例如计时器达到其设置时间、接收到网络数据包等）保证此类通知。