I create an URI with a fragment (aka anchor #).
UriBuilder ub = new UriBuilder("file://path/doc.pdf");
ub.Fragment = "chapterX";
The url is shown correctly in the debugger (ub -> file://path/doc.pdf#chapterX
). But when I assign it to a WebBrowser control, the fragment part gets lost (reason for the fragment see PDF Open parameter).
this._myWebBrowser.Url = ub.Uri;
// Alternative this._myWebBrowser.Navigate("file://path/doc.pdf#chapterX");
When I check this._myWebBrowser.Url
it displays file://path/doc.pdf
. this._myWebBrowser.Url.Fragment
is empty - also readonly and cannot be assigned.
As C.Haas has shown below, the concept works in general, for some reasons it fails when the resource is a LOCAL(!) pdf file.
Summary:
- Works if protocol is http
- Works if resource is .htm / .html - even when protocol is file://
- Works if file is .pdf and protocol is http (same as 1.)
- Fails if refers to local pdf file, fragment gets lost
Any workaround for this?
Revisions:
- 20110219 - Update thanks to C.Haas. As Chris shows, OK with ".htm", but fails with ".pdf" and only if it refers to a local resource.
- 20110218 - Some finding thanks to abatishchev: If I use
Navigate
it does not work neither, butNavigate
offers to provide a frame name. In this case an external IE pops up (because there is no frame in the control's page) and then the URL with fragment is correctly displayed. Is not what I want, but it shows me the URL itself is correct and the bug seems to be within the control.
How about
wb.Navigate("http://example.com#chapterX");
?
来源:https://stackoverflow.com/questions/5033589/fragment-anchor-in-net-4-webbrowser-control-getting-lost-with-adobe-pdf-rea