In this stage, I will show how the link we generated in the previous link causes the page to show correctly to the user.
In the previous post, we created a link that looks like this:
/Docs/SomethingInteresting.aspx?url=[url to saved workbook]#[range]|[title]
We take the string that comes after the hash and split it around the pipe (|) symbols. We then look at the two parts – the first one is the range we need to select in the EWA and the second is the title of the find. We take the title and put it at the top of the page (remember, in the part 1 post we gave the title we create an ID – we use that here).
The first element of the array (the range) we take and pass into a call to getRangeA1Async() which I already showed in a previous post. We also pass a callback that will run when EWA returns the requested range (hashGetRangeComplete()).
This method takes the range and activates it by calling the activateAsync() method. Note that we do not pass a callback.
So here’s, in a nut shell, what happens when this page loads.
1. If the URL is specified, the page will load the workbook it points to. If it’s not, it will load the default workbook as set in the web-part filter.
2. If there’s a hash, the page will look at it and select the range that’s in that hash, making sure the selection that was originally saved is selected in the EWA.
3. The title the person who did the publish is then also placed at the top.
The next post will summarize everything the app does, from a technology point of view and will discuss places where the “app” could be made better.