08-23-2011 05:57 PM - edited 08-23-2011 06:10 PM
Hello,
I am using onChange in my Playbook app in a <select> element within a form. The form is used to add items to a database. Each time I call the form I reset it.
Several select boxes are interdependent. So, when the user clicks one box, that determines what to display in the next box, and so on. The onChange for each select box calls the functions that populate the next select box.
This works without any trouble at all in Chrome. It also works in the PB, but only the first time through. If I try and add another item to the database (ie.call the form again), the form is reset and the select boxes are all reset to the first value, which is simply a message value, If I then try and choose the same item as before the PBook doesn't recognize the onChange event as being a change, even though I even manually reset the select boxes in the form so that the selectedIndex is for the first index value in the list, which is never the one that I use. If I first select a different item, and then go back and select the one I wanted, the event fires.
Again, I thought that perhaps the onChange was somehow tracking the previous selection (ie. before the form was cleared) so I tried to manually reset the select boxes by changing the selectedIndex value when the form is generated/displayed the next time, but that didn't seem to work.
EDIT--I should also mention that this only seems to be a problem in the PB sim and the device itself. Ripple does not seem to have this problem.
Any thoughts? I have searched on this forum and found some other people with similar issues whose posts were never answered from a few years ago, so I was hoping the state of knowledge had changed.
08-24-2011 01:34 PM
No thoughts whatsoever?
This appears to be a bug with how the PB handles this event. It is a simple event, that works perfectly in Chrome, and in Ripple, but not on the device itself. The device doesn't seem to reset the onChange event from one call of the form to another.
Even if anyone knows how to manually reset the onChange "memory" in Javascript, that might be helpful.
08-25-2011 04:26 PM
Have you tried the latest Release of the PlayBook OS that went out just the other day.. If it was a browser bug it may have been fixed.
08-25-2011 10:48 PM
Hi,
Thank you, tneil, for your response.
Yes, I updated the device last night with the OS update that was pushed out, but it didn't seem to have any effect. It appears to just be the case that whatever Javascript uses internally to track the onChange event (ie. whether or not the selection has changed) does not reset with a form reset, although it resets in Chrome.
The onChange event clearly works on the PB, just not more than once if you are, like I am, trying to have a responsive form that adapts to the user's selections automatically and populates the next <select> based on the previous <select>'s values (ie. if the previous <select>'s value happens to be the same as before even though the form has been reset for a new entry).
Thank you anyway, but it looks like I will need to design a new form around the bug.
08-26-2011 10:25 AM
08-26-2011 11:08 AM
Hi ababut,
Thanks for your response. I think you have hit it on the head, and the device is remembering my last selection no matter what. I have actually already tried resetting the selectedIndex, but that doesn't work either for some reason.
Again, this behaviour is different from the Chrome browser, or even the Ripple emulator. It wouldn't be such an issue, I guess, except for the fact that my subsequent select elements depend on the previous selection calling the onChange to generate the selections for the next select tags. If the device doesn't recognize the event, and the onChange isn't called, then the next select tags aren't populated at all, which means the form doesn't work correctly.
09-06-2011 03:30 PM
Here's a hack that worked for me:
Playbook suspends JavaScript execution while modal dialogs (such as the select popup) are open, and resumes it after the dialog closes.
After the first time that a change event is fired on each <select> element, bind the element's tap/click events. Your click handler should, after a timeout of 500 ms, manually trigger a change event -- which won't actually happen until the dialog closes. Depending on what your onChange handlers are expecting, you may need to do some additional bookkeeping to make sure that you never trigger the change event twice in a row.