We have a developed SQL Server ReportViewer webpart for MOSS 2007 and WSS 3.0. The webpart is nothing fancy, basically just a wrapper around the ReportViewer web control that comes with Visual Studio 2008, but it allows us to customize it somewhat.
The problem arose when one client noted that the reports don't scroll to the expanded row when using drill down in SSRS - really annoying for the users! The drill down was a standard visibility toggle so it should work, and indeed it was fine if you accessed the report directly from the report manager.
I didn't really find anything when googling, except that using the asynchronous rendering mode would solve it, or upgrading to the ReportViewer from Visual Studio 2010. Async rendering has its own peculiarities and was not an option at this stage and neither was changing the development environment.
The solution turned out to be quite simple, although a bit "hackish". I reduced the problem to a simple webform with only the webcontrol on it. That allowed me to realize that the webcontol indeed tries to scroll to the expanded item by rewriting the hash part of the URL. However it seemed that the IDs that the hash part (does it have an official name? must investigate…) pointed to were rewritten. Most likely because it's included as a web control. Long story short: peering over the generated code I realized that the IDs had a prefix but they still ended with the hash part. Using a bit of jQuery solved that part:
setTimeout("Jump()", 2);
function Jump() {
var hash = window.location.hash;
hash = hash.substring(1, hash.length); // remove the #
if (hash != "") {
var hash2 = $("div[id*='" + hash + "']").attr('id');
window.location.hash = hash2;
}
}
The time out was needed becasuse the hash was written by another javascript and we had to wait for it to finish.
