当BREW运行后，首先操作系统（REX）中的UI task会捕捉到各种事件，此时UI task通过aee_dispatch将事件分发至BREW环境中。BREW环境再通过aee_sendevent具体分发事件到目的地，在两种不同的情况下将走不同的流程。
如果当前没有激活的Dialog，则紧接着IAPPLET_HandleEvent被自动调用来处理事件，而此时调用的IAPPLET_HandleEvent其实就是用户注册的app_HandleEvent。此而实现应用捕捉到事件并处理的机制。在用户的app_HandleEvent中，用户可以将事件继续分发下去，如通过调用IMENUCTL_HandleEvent等将事件下发给各种控件处理，IMENUCTL_HandleEvent的返回值标示空间是否处理了此事件，此时，app可以继续处理该事件或直接返回。
如果当前有激活的Dialog，则基于Dialogde事件被自动调用，从而使得事件被Dialog最先截获，而Dialog之后的处理是检查包含的控件中哪个处于焦点，并将事件下发给他的handleEvent来处理，同时根据其返回值来判断其是否处理了该事件，当其返回FALSE后，对话框继续将事件转发至该Dialog注册的Handlevent（如果有的话），如果该HandlEvent仍然返回FALSE，BREW继续将该事件转发至app_HandleEvent。
也就是说，一旦当一个Dialog处于激活的状态时，AEE层会把所有的事件直接发往该Dialog，注意此时并不是调用Dialog的HandleEvnet，该Dialog会自动的调用处于焦点控件的HandleEvent来处理此事件，只有当该空间没有处理该事件时，Dialog注册的HandleEvent才会被调用。
而没有Dialog处于激活状态时，AEE会把事件发往该app的HandlEvent，此时app可以通过手动调用控件的HandleEvent来将事件下发给空间，并可以在空间处理了事件后，继续对该事件进行处理。
例如：
switch(eCode)
{
case EVT_APP_START:
return TRUE;
case EVT_APP_STOP:
return TRUE;
case EVT_KEY:
IMENUCTL_HandleEvent();
ITEXTCTL_HandleEvent();
…………
return TRUE;
}
使用Dialog的方式创建应用时，各种事件被自动处理，从而简化了代码量，但也使得事件流程更加晦涩，用户的应用程序不能直接控制他。