Tags
People
Badges
Help-
CORE FRAMEWORK
FEATURED COMPONENTS
-
RESOURCES
-
LEARN ZK
RESOURCES
Hi,
I tried to update from 5.0.4 to 5.0.5
but a datebox field change its behavior
<datebox id="dbGiorno" cols="20" format="dd/MM/yyyy" mold="rounded" constraint="no past"/>
when I click on the day number the onChange don't fire
but it fires where I click outside of datebox field ( lose focus )
Does the forum have info about problem with datedox on 5.0.5 ?
I searched on bug tracker but I did not find anything
Thank you
Giuseppe
Giuseppe,
It seems to me that the behavior change is the result of a bug fix and that 5.0.5 is now working correctly.
From an application perspective, I would think that it would be preferable for the "onChange" event to be fired when a user has changed a value, not when they are in the process of doing so (e.g. opening the calendar to choose a date).
If you want to capture when a user is in-process, you could try the "onClick" event which will capture when the user clicks in the date field (not the day number) or perhaps the "onFocus" event which will capture when the user clicks in the date field OR the day number.
Sorry I couldn't be of more help.
Todd
Thank you Todd,
I will check the 5.0.5 datebox events behavior with a test program
to undertand wich one is best for my application
It is importart to know that 5.0.5 behavior is corrent and it isn't a bug and in the
future will be the same
Giuseppe
Gidday Todd
I have the same problem, I have been using the onChange event to update other elements and datebox this will now only trigger the event when you actually leave the datebox field i.e. loose focus.
This is wrong in my opinion, the previous behaviour of when you click on the date you want and the month view closes should trigger the event
Currently the user must leave the datebox for the onChange event to trigger forcing the user to go back to the datebox again to try another date, quite baffling to my users, rolled it out yesterday and the phone has been running hot!
Is there a work around for this ?
Will you be changing this behaviour back ?
cheers pb...
To me the 5.0.5 behavior seems more correct than before. It is now consistent with all the other input fields, where you need to leave the field to get the event.
Before 5.0.5, there were onChange events fired for each change in the calendar popup, e.g. when you increment the month 5 times. But setting up the calendar for a desired date, which may require more than one click, is similar to plain editing an input field, so onChanging would be more appropriate in my opinion.
Sorry, I just said that it looks most appropriate to me, but I never used the onChanging event.
Still, I don't understand the use case. If a user wanted to select a certain date and did clicked on three different days in the calendar (because he missed the correct day twice), then you got three onChange events with 5.0.4.
What do you do with all these events?
Moreover, if a user decided not to use the calendar and did the changes in the text field, no onChange event was raised, even if the result of the editing was the same.
I had a use case where this onChange event really hit me and I am glad that this is consistent with all the other input fields now.
Try to file a feature request for onChanging if this is really not working for you.
My use case is as follows
Form of payroll data is displayed below a Datebox
Date is selected in Datebox and the relevent payroll data is displayed below
The user needs to scan the data below and not necessarily interact with the form, which means the cursor may not leave the Datebox
Problem with I am having with 5.05 is that although the Datebox shows the new date selected, the data below is not updated, this confuses the user
It seems to me that Datebox should behave more like a Combobox where when the value changes the onChange event is thrown, not when the Datebox looses focus
see diff behaviour in these two videos
http://attainconsult.com/temp/zk_datebox_new_5.05_behaviour.mp4
http://attainconsult.com/temp/zk_datebox_org_behaviour.mp4
It may be a mismatch on editing styles in that the datebox allows text to be entered as well as providing a selection popup
I would be happy with a work around, currently I am going to stay on the previous version as this behaviour is too mistake prone IMO
cheers pb...
Asked: 2010-11-10 02:24:32 +0800
Seen: 848 times
Last updated: Feb 14 '11
