-
My apologies. This is all greek to me so I am trying to better understand. So where in the code does it tell it when to go back and get the newest version of the report? The time you have (9000) says how often to switch pages. But I also had (or at least I thought I had) a portion that stated to go back in 5 minutes and get the newest version. I assume it's this part? (sInstance=Last&sReportMode=weblayout';)
-
Oh never mind. I see it. Thanks!
-
Just as a point in fact, there's no need to go back every 5 minutes if every time we switch pages we get the latest version of that page. And that's what this code is doing. We could modify it so that it only forces the latest version every 5 minutes. But you might end up with an out of date page for up to 5 minutes, like if it changes right after the last forced look for a new version. However, it would mean less round trips to the server. If this is an intranet though, that shouldn't be much if any of a consideration.
-
Ah ok I think I am getting it now. For my own knowledge, how would I modify the code so that is only forces the version every 5 minutes? Our data doesn't change that often so less trips to the server might be the better option.
-
Replace this part:
Code:
function loadIframe() {
var page = pages[(p = ++p % pages.length)], bust = 'bustcache=' + new Date().getTime();
page = page.search? page.href + '&' + bust : page.href + '?' + bust;
document.getElementById('if_one').src = page;
setTimeout(loadIframe, 9000);
}
with:
Code:
var bustdate = new Date().getTime();
setInterval(function(){bustdate = new Date().getTime();}, 1000 * 60 * 5);
function loadIframe() {
var page = pages[(p = ++p % pages.length)], bust = 'bustcache=' + bustdate;
page = page.search? page.href + '&' + bust : page.href + '?' + bust;
document.getElementById('if_one').src = page;
setTimeout(loadIframe, 9000);
}
That way the cache busting query variable will only update every 5 minutes (1000 milliseconds times 60 times 5). The rest of the time the browser can show a cached copy, that is as long as (like I mentioned before) the server isn't serving it with a no cache header. And something I didn't mention is that if the page itself has a meta tag no cache header, that too can force the server to send a fresh copy each time.
But as I also said, as long as this is an intranet, repeated requests to the server (every 9 seconds) shouldn't be a big deal. But it might. Depends on the setup.
-
Thanks!! Is there any reason this code would change the scroll bar on the right to move down a bit? Every time it changes pages, the right hand side scroll bar moves down a bit and cuts off the top of the report being displayed :(
-
Do you mean both versions, or only this latest version? And, when it does that, can you use the right scrollbar to scroll up to see the top of the report?
I'm guessing that the answer to both questions is yes. Either way it would be hard to know for sure why it's happening without seeing it. Are their any elements on the reports that demand focus? That could be an explanation. When I tested this out, one of the pages I loaded was Bing's main page. It sets focus on its search input, so the iframe would always scroll to it when Bing loaded. After that, one had to manually scroll back up to see the top of any page loaded into the iframe.
It could also be javascript on the report pages telling them to scroll to a certain point on the page (window.scrollTo(x, y)) or by a certain amount (window.scrollBy(x, y)), or a named anchor (I see none of those in the page's URLs though). As I say though it would be hard to tell without seeing it. There might be some other explanation. It might even be something about the iframe itself. But I doubt that.
Was there any version where this did not happen? If so, which? Before answering, try it again to make certain it's not doing it. Like before when there was just one page, it might not appear to do it except on reloads, which were few and far between.
When I have more time, I will look into a possible fix. As long as both the page with the iframe and the reports are on the same server, we should be able to get the iframe to scroll to its top after loading.
-
I was just playing with this and it seems quite possible that it's not the iframe, rather the top page that's scrolling. Can you tell which it is?
-
I'm guessing it could be either or both, so try adding this code as shown:
Code:
. . . ge = pages[(p = ++p % pages.length)], bust = 'bustcache=' + bustdate;
page = page.search? page.href + '&' + bust : page.href + '?' + bust;
document.getElementById('if_one').src = page;
setTimeout(loadIframe, 9000);
}
loadIframe();
function scrolltotop(){
setTimeout(function(){
window.frames[0].scrollTo(0, 0); //iframe
window.scrollTo(0, 0); //top window
}, 100);
}
if (window.addEventListener){
document.getElementById('if_one').addEventListener('load', scrolltotop, false);
}
else if (window.attachEvent){
document.getElementById('if_one').attachEvent('onload', scrolltotop);
}
</script>
.
That should take care of both/either. You can experiment by removing the one for the iframe and see if it still works, and likewise for the one for the top window after bringing back the iframe one. It's probably just one or the other. Probably the top window.
-
Turns out it only scrolls when I move it from my computer screen over to my TV monitor that I have hooked up. I guess I will need our IT to look into why it's scrolling for the TV monitor. Thanks again for everything!