Focal Point Banner


As of December 1, 2020, Focal Point is retired and repurposed as a reference repository. We value the wealth of knowledge that's been shared here over the years. You'll continue to have access to this treasure trove of knowledge, for search purposes only.

Join the TIBCO Community
TIBCO Community is a collaborative space for users to share knowledge and support one another in making the best use of TIBCO products and services. There are several TIBCO WebFOCUS resources in the community.

  • From the Home page, select Predict: WebFOCUS to view articles, questions, and trending articles.
  • Select Products from the top navigation bar, scroll, and then select the TIBCO WebFOCUS product page to view product overview, articles, and discussions.
  • Request access to the private WebFOCUS User Group (login required) to network with fellow members.

Former myibi community members should have received an email on 8/3/22 to activate their user accounts to join the community. Check your Spam folder for the email. Please get in touch with us at community@tibco.com for further assistance. Reference the community FAQ to learn more about the community.


Focal Point    Focal Point Forums  Hop To Forum Categories  WebFOCUS/FOCUS Forum on Focal Point     [CLOSED] Issue with onInitialUpdate() and IE6 (with workaround)

Read-Only Read-Only Topic
Go
Search
Notify
Tools
[CLOSED] Issue with onInitialUpdate() and IE6 (with workaround)
 Login/Join
 
Virtuoso
posted
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. Frowner


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 Wink

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


WebFOCUS 8.1.03, Windows 7-64/2008-64, IBM DB2/400, Oracle 11g & RDB, MS SQL-Server 2005, SAP, PostgreSQL 11, Output: HTML, PDF, Excel 2010
: Member of User Group Benelux :
 
Posts: 1669 | Location: Enschede, Netherlands | Registered: August 12, 2010Report This Post
Virtuoso
posted Hide Post
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.


Alan.
WF 7.705/8.007
 
Posts: 1451 | Location: Portugal | Registered: February 07, 2007Report This Post
Virtuoso
posted Hide Post
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


WebFOCUS 8.1.03, Windows 7-64/2008-64, IBM DB2/400, Oracle 11g & RDB, MS SQL-Server 2005, SAP, PostgreSQL 11, Output: HTML, PDF, Excel 2010
: Member of User Group Benelux :
 
Posts: 1669 | Location: Enschede, Netherlands | Registered: August 12, 2010Report This Post
Virtuoso
posted Hide Post
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.


"There is no limit to what you can achieve ... if you don’t care who gets the credit." Roger Abbott
 
Posts: 1102 | Location: Toronto, Ontario | Registered: May 26, 2004Report This Post
Virtuoso
posted Hide Post
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
    }
}


WebFOCUS 8.1.03, Windows 7-64/2008-64, IBM DB2/400, Oracle 11g & RDB, MS SQL-Server 2005, SAP, PostgreSQL 11, Output: HTML, PDF, Excel 2010
: Member of User Group Benelux :
 
Posts: 1669 | Location: Enschede, Netherlands | Registered: August 12, 2010Report This Post
  Powered by Social Strata  

Read-Only Read-Only Topic

Focal Point    Focal Point Forums  Hop To Forum Categories  WebFOCUS/FOCUS Forum on Focal Point     [CLOSED] Issue with onInitialUpdate() and IE6 (with workaround)

Copyright © 1996-2020 Information Builders