A frequent use of the Control::keyPress event is for things such as a 'filter' or 'quick search' text box that will filter the list of entries displayed in say a table of results on that form. This is used to provide a 'better' user experience than typing in the desired filter and then pressing a refresh button or similar. The downside to this approach is that every key press then needs to do a round-trip to the AppServer and back again to execute the Control::keyPress logic. If you're connected via a slow connection, this can add significant frustration, especially for users who are fast typists and spend a long time waiting for the thin client to finally catch up with their typing.
If we could have a Control::dataChanged event, for those control types which allow user input, that is generated after a new Application::dataChangedDelay property of elapsed milliseconds without the user typing anything new into the control. This would allow us to customise this 'auto search' behaviour in a way that doesn't reduce the responsiveness of the application for fast typists, while still allowing us to have the nicer user experience of 'auto-refreshing' the results list without the need to click a refresh button or similar.
It may be worth considering having a Control::dataChangedDelay design time property. When this is zero, the default, it uses the Application::dataChangedDelay value for the delay. This application level delay may be all that is required for some/most applications. However, when there is a data entry field which has more complex data structure, such as say a UUID format or similar form which is slower to type, developers could easily increase the delay for that specific control by setting a non-zero value for the Control::dataChangedDelay design time property on that control.