Bug: ChangeOnKeypress not working for DateTimeItems if useMask is set to true

[seraksab]

Hi

If looked through the documentation of both 'setChangeOnKeypress' and 'setUseMask' but couldn't find anything indicating that change events won't be fired if both are set to true.

So i suspect this is a bug.

Here's a quick test class to reproduce the issue:

public class Test implements EntryPoint {

	@Override
	public void onModuleLoad() {

		final Layout layout = new Layout();
		final DynamicForm form = new DynamicForm();
		final DateTimeItem item = new DateTimeItem("testName", "testTitle"){
			{
				setUseTextField(true);
				setChangeOnKeypress(true);
				setUseMask(true);
				setValue(new Date());
				addChangedHandler(new ChangedHandler() {
					
					@Override
					public void onChanged(ChangedEvent event) {
						SC.say("Changed fired");
					}
				});
				addChangeHandler(new ChangeHandler() {
					
					@Override
					public void onChange(ChangeEvent event) {
						SC.say("Change fired");
					}
				});
			}
		};
		form.setItems(item);
		layout.addMember(form);
		layout.draw();
	}
}

If both 'setChangeOnKeypress' and 'setUseMask' are set to true, no change or changed events are fired on keypress.
If i set 'setUseMask' back to false, both events fire as expected.

I'm currently using the latest build available (27.05.2015).

Best regards,
Seraksab

[seraksab]

Hi

Sorry to push this topic again.
Just wanted to ask whether you have look into this already and can reproduce it?

I just switched to the latest build (v10.0p_2015-06-20/LGPL Development Only (built 2015-06-20)) today and I'm still having this issue..

[Isomorphic]

A quick update - we see the behavior you mention and we'll look into whether it requires a fix.

In the meantime, you can probably get what you need by applying your changeOnKeypress setting and change handlers to a TextItem and passing that to DateTimeItem.setTextFieldProperties().

[Isomorphic]

One question here - what are you going to do in a change handler on a per-keypress basis while the user is inputting a date?

In most cases, the users first few keystrokes are going to be too ambiguous to even try interpreting as a date. For example, if you were filtering something on a per-keystroke basis, you'd end up performing a set of wildly different and useless search operations for the first keystrokes.

[seraksab]

Well quite a few things actually.

First of all, the dateTimeItem in this context is used with a few other formItems on a configuration page that allows to set various values.

These actions are performed on a per-keypress basis for all of them:
- check whether the current value differs from the original one to show/hide an 'undo' button and change style classes.
- check whether the current value differs from the default value to show/hide a 'set default' button.
- enable/disable other formItems or navigation buttons based on the value.

The dateTimeItem in particular is used to configure the start and end date of a task that can be executed in various intervals (daily, monthly, quaterly, etc.)
So in addition to the above a label is updated on every keypress (if a valid date is currently entered) that contains the date of the next run of the task as well as a "countdown" displaying how much time is left until the task would execute. (e.g. 'Next run: 22d 02h 29m 40s (7/17/2015, 2:33:00 PM)').

[Isomorphic]

So all of this strongly suggests that you don't want to execute this logic on keypress. As with the example of filtering to see, if you react on a per-keypress basis, you're just going to be constantly updating parts of the screen with useless information, because the user input is incomplete.

Instead, the default timing of the change handler firing (when the user leaves the field, picks from the DateChooser, etc) is already the right time to update the display.