Basically, the load statement interacts with the innerHTML property of the SELECT tag, meaning the OPTION tags inside. But the .load statement is different than the .html statement because .load will go get a remote page over AJAX, pass it a value, and pull the results back to paste into an innerHTML.
I could have substituted the .load statement with:
1. FF and all other browsers but IE let you swap SELECT OPTIONS on the fly. To handle things with IE, you have to replace the entire SELECT element, not the OPTIONS inside it.
$('#test').change( function() {
alert('you changed me to: ' + $(this).val();
});
...this only works until that SELECT element is redrawn. Why would you redraw it? Well, if you have one select box choice that updates another select box -- that's why. So, if you did that, you would lose the attached jQuery event. The fix is to put an onChange="myfunction(this);" in the SELECT element once you redraw it so that you will always be able to catch that event.
I also discovered that the 'this' which is passed like so: onChange="myfunction(this);" can be converted back into a jQuery $(this) like so:
function myFunction(o) {
$(o).replaceWith("I'm replaced'); // just a sample where I demonstrate converting the Javascript 'this' object into the jQuery $(this) object
}
3. Therefore, noting the issue in # 1, you can't exactly use .load() or .html() to replace those options. You would use .load(), by the way, when you want to make a quick little AJAX call back to another page and then return its results into another element. So, the fix is to do it like this with a combination of $.get() and .replaceWith():
So, if someone changes the select box fldType, it then performs an AJAX call with 'edit_section_get.php', passes it the query params ?id=$(this).val()&tag=fldSectionKey (replacing Javascript with their actual values), and then on callback it receives data and replaces the entire select box fldSectionKey because edit_section_get.php did an echo statement of an entire SELECT box, complete with options and all.
So, my problem is fixed, but I had to go about it in a workaround, as you an see.
kaszu wrote:Works for me in FF, IE6, IE7. Problem is not with this script, is there any other JS on that page? Is IE7 showing any errors?
The code sample at the top of the thread will load without errors, but if the get_subsections.php page only returns OPTION elements, not the full SELECT element complete with OPTION elements inside, then you will get an unintended result on IE -- no options show up.
The workaround is to replace the entire SELECT element. In my previous post, I demonstrate this technique.
I just don't get it. I have IE6 and IE7 and they both fail. FF, though, works fine. I replaced the whole SELECT statement instead of just the OPTIONs inside, and all was well again.
Wait a minute -- what version of jQuery are you running? Maybe my version is old and perhaps they somehow have fixed this?
Dude! I figured it out thanks to your sample. Here's what I did wrong.
Instead of Vista, I was using Windows 2008 Server because it was free and acts sort of like a mix of XP and Vista (when set in classic mode). Well, W2K8S has IE7 in a super-tight security mode, which then wouldn't download jQuery. When I added your site to "Trusted Sites", however, then refreshed the page, your example worked 100%.
Long story short -- it was my security settings in my browser.