Community
Participate
Working Groups
The selection event of the DateTime widget is lost, if the widget is disposed before the internal timeout of 500ms expired. This can cause a wrong value on the server side. In my case it happens in this scenario: 1. A Dialog is opened 2. A DateTime widget is shown with an initial value 3. The user changes the value 4. The user closes the dialog If this sequence is done fastly, the server has the wrong value for the DateTime widget. The same scenario with a Text widget works fine, because the event is always sent with the next request. This can also be reproduced with the control demo: 1. Change to DateTime tab 2. Add a selection listener 3. Change the value of the DateTime widget 4. Leave the tab
Actually, the widget even crashes the application when disposed before sending the changes. Possibly the symptoms of the problem have changed since the version the reporter used. The fix in any case would be to add the parameters immediately and also send the request immediately if a selectionListener is present.
Fixed in CVS HEAD as described above in DateTimeDate.js and DateTimeTime.js. DateTimeCalendar did not have the issue.
The fix was no good because the server can now be flooded with events if the spinner is pressed down. I will try to update the fix.
The problem is with re-introducing the delay that if another widget is selected within that delay (like the original scenario), one of the events will get lost because one Request can only have one WidgetSelected event.
Fixed in CVS HEAD for good (i think). It now sends the request if the value doesnt change for 100 ms. Its still possible to loose the event if the user is really fast (using a combination of mouse and keyboard for example), but its very unlikely. To fix it 100% we would need the protocol implementation. It cant crash in any case anymore.
