The JADE 2022 release meets tomorrow’s business demands.
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.
BeeJay
Good point Kevin and that would mostly work. Unfortunately it won't handle where you want a parent control to have its change event fire if any descendant controls are changed. We'd also still have that age old issue with the ComboBox control where it doesn't fire the change event when you select an entry in the list with the arrow keys and/or by typing the first character of an entry in CombobBox with style = 2 - Dropdown List. If both of these situations could be 'resolved' then simply delaying the existing change event and combining all the changes into a single delayed change event would solve the issue at hand. Perhaps the changeEventDelay could also apply to the click event for a ComboBox control, since that is a special kind of 'change' to the control?
Perhaps it'd be less confusing if the new delay setting were applied to the existing change events rather than introducing another very similar event? But that would depend on whether the existing change events can be promoted/redefined on Control, as it would be useful to have a generic change event for all controls, which if nothing else, was invoked when a child control change event was triggered (particularly for custom controls made up of other controls).
This event should probably fire immediately when the control loses focus, if the data was changed prior to losing focus, rather than waiting for the completion of the relevant dataChangedDelay.
Using arrow/home/end keys to re-position the carat within the control should also be considered 'user typing' activity.
It may also be worth considering having this event for a parent control which can contain controls that support data entry. This would be useful if you have say several controls which form the filter criteria. You could then group those controls with a common parent in their hierarchy, and have that common parent control implement the Control::dataChanged event. In this situation, the event would not fire immediately when individual controls with that parent control in their hierarchy lose focus to another control which has that parent in its hierarchy, but it would fire immediately when focus is lost to a control which does not have that parent control within it's hierarchy.