Hello again,

We were having a curious issue where a script called through onInitialUpdate() doesn't update our form elements in IE6. It works in Firefox and even in IE7 apparently (we don't have the latter), but not in IE6 - which we happen to use everywhere! I found a workaround, which gets described below, but it's UGLY.

It used to work before we upgraded our WebFOCUS (from 7.6.8 to 7.6.11), so we suspect this bug is triggered by a difference in the way the AJAX calls are processed (embedded procedures on form elements are new since our upgrade, for example).
It seems likely that this is an Internet Explorer 6 bug, but we didn't run into it on this same page before the upgrade.

The code is:

function initializeFromUntilYears()
{
	var currDate = new Date();
	var y = currDate.getFullYear();
	var m = currDate.getMonth() +1;

	var fy = document.getElementById('FROMYEAR');
	var fm = document.getElementById('FROMMONTH');

	var uy = document.getElementById('UNTILYEAR');
	var um = document.getElementById('UNTILMONTH');
	var i;

	//alert('Find fromyear '+y)
	for (i = 0; i < fy.options.length; i++)
	{
		if (fy.options[i].value == y)
		{
			fy.selectedIndex = i;
			uy.selectedIndex = i;
			break;
		}
	}

	um.selectedIndex = 0;
	for (i = 0; i < um.options.length; i++)
	{
		if (um.options[i].value == m)
		{
			if (i > 0)
				um.selectedIndex = i-1;
			break;
		}
	}
	//alert("Done.");
}

function onInitialUpdate() {
	initializeFromUntilYears();
}

If we uncomment the

alert("Find fromyear")

at the top of the main function, then the dropdown boxes with the four ID's as mentioned start changing as they should! Without the alert they stay in their initial positions.

It gets "funnier"... I can alert the selectedIndex values of those boxes at the end of the function, and they are CORRECT! Still, the dropdowns stay in their initial positions and don't update to the selected indexes.


As usual, firefox treats the page like a pro, without showing as much as a javascript warning. Even IE6 reaches the end of the function (it executed my alert after all), so presumably it accepts the code and the output of my alert even confirmed it changed the selectedIndexes of these dropdowns! Yet, it doesn't actually change them. It doesn't show an error either (I turned those on in the "Advanced" settings).

Now, we did find a solution. If we change the code like below, then it works!

function onInitialUpdate() {
	//initializeFromUntilYears();
	setTimeout("initializeFromUntilYears()", 1);
}

For some reason either the 1ms delay or the event that it fires cause our dropdowns to get "unstuck". Very very very peculiar!

Anyway, if people run into this, the above is a possible workaround. In the meantime I'd like to find out why this is happening - Let the discussion start

This message has been edited. Last edited by: Kerry,

I have had this issue in the past, particularly in IE6, when functions seem to fire early. The best cure I found was to use the following javascript code:

// example call - addEvent(window, 'load', handleVars);

function addEvent(obj, evType, fn){
 if (obj.addEventListener){
    obj.addEventListener(evType, fn, true);
    return true;
 } else if (obj.attachEvent){
    var r = obj.attachEvent("on"+evType, fn);
    return r;
 } else {
    return false;
 }
}

So in your example, the following might work well:

function addEvent(obj, evType, fn){
 if (obj.addEventListener){
    obj.addEventListener(evType, fn, true);
    return true;
 } else if (obj.attachEvent){
    var r = obj.attachEvent("on"+evType, fn);
    return r;
 } else {
    return false;
 }
}
function onInitialUpdate() {
addEvent(window, 'load', initializeFromUntilYears);
}

The addEventListener is for IE and attachEvent for other browsers, multiple events can be added. The parameter obj is the element, evType is an event like click, or as here, load and then fn the function to call.

It is a clean method of working and I have used in many areas, both self service and WebFOCUS applications.

quote:

Originally posted by Alan B:
The addEventListener is for IE and attachEvent for other browsers, multiple events can be added. The parameter obj is the element, evType is an event like click, or as here, load and then fn the function to call.

It is a clean method of working and I have used in many areas, both self service and WebFOCUS applications.

Actually it's the other way around; addEventListener is for standards-compliant browsers (Mozilla, Opera, Safari, etc) and attachEvent is for IE. I believe from IE7 up it also listens to addEventListener though.

Regardless of that, I'm not so sure you're actually trying to solve the same issue I was seeing. You're re-defining the window-onload event handler, which fires once the page has finished loading. The issue here is almost certainly caused by the asynchronous calls (AJAX) performed to populate the drop-down boxes AFTER the main body finished loading. Ergo, I think that your event handler could still be called too early to matter, it triggers on the wrong event.

I'm fairly sure the implementation by WebFOCUS tries to do the right thing where it comes to calling a callback function once a dropdown has been populated, but IE6 does not handle it properly. It actually performs the function (and on the correct data too!), but it doesn't reflect the results in the dropdown widget.

I opened this ticket for the bug: http://techsupport.information...ry.jsp?case=62422516

This may be more complicated than it appears ... as you've noticed. I've noticed that the onInitialUpdate can actually be called twice depending on the browser you are using. Also, it can fire before DOM is completely loaded, and therefore nothing will work anyway. The only way I've been able to COMPLETELY control execution and loading in the past is to implement a singleton class (singleton'ish ... this is JS afterall). I used the singleton to maintain a state of only one instance of a variable to control the load of js files or execution of functions. The functions would check the state of the loading document before it would try to execute. The the document was shown as still in a loading state, then set a timeout for the re-execution of the function.

I found a few interesting links:

Someone with the same issue and a workaround: http://www.webdeveloper.com/fo...wthread.php?t=186304
Apparently this is a known issue and setting the selected-attribute on the appropriate option instead of setting selectedIndex works.

The Microsoft-sanctified method of initialising the XmlHTTP ActiveX control: http://blogs.msdn.com/b/xmltea...ternet-explorer.aspx
The current approach is almost right, but doesn't cater to more modern versions of the library. MS's solution doesn't look like it's future-resistant though, for newer versions the list of versions to check against needs to be updated.

I also noticed that with the current browser-check approach to initialising xmlhttp it seems likely that the ActiveX control gets used for IE7 and up, while for those browsers the preferred method is using the (now standards compliant) XMLHttpRequest object that's also supported by all other major browsers.
As an aside, browser-checks are frowned upon by JS experts (sometimes there's just no way around those checks though). The advised is to use them as little as possible. Using capability-checks instead makes you more resistant to future browser updates.

It's probably better to change that check to something like below:

try {
    // create an XMLHttpRequest object
    xmlHttp = new XMLHttpRequest();
}
catch(e) {
    // assume IE6 or older
    try {
        var progIDs = ['Msxml2.DOMDocument.6.0', 'Msxml2.DOMDocument.3.0'];

        for (var i = 0; i < progIDs.length; i++) {
            try {
                xmlHttp = new ActiveXObject(progIDs[i]);
                break;
            }
            catch (ex) {}
        }
    }
    catch(e) {
      // Throw some error
    }
}