QDesktopServices::openUrl with location hash fails on Windows and Mac

Hi there,

I'm using an HTML-based help file in my application, designating specific topics using the location hash, like this:

Code:

---

.../help.htm#theTopic

---

I'm opening the help file using QDesktopServices::openUrl, like this:

Code:

---

QDesktopServices::openUrl(QUrl("file:///[the path]/help.htm#theTopic", QUrl::TolerantMode));

---

This works great on Linux -- the Help file opens at the right location -- but on Windows the location component of the URL is ignored. The browser opens correctly, but it shows only "help.htm"; the hash component has disappeared.

Does anyone have any suggestions as to why this might be happening, or how to fix it?

All help appreciated,
Martin

have you tried without #theTopic ?

Yes, of course.

On Linux, with #theTopic, I get the browser opened to help.htm#theTopic. (Correct)

On Windows and Mac, with #theTopic, I get the browser opened to just help.htm. (Broken)

On all platforms, without #theTopic, I get the browser opened to help.htm (Correct)

If you paste your value "file:///[the path]/help.htm#theTopic" into the Windows Run dialog does it give you the correct result? It doesn't for me on Win XP with IE 8 which implies that the problem is outside Qt.

Just discovered this thread as I'm having the exact same issue right now and was wondering, mholmes, if you found a work-around. I've noticed that on a Mac, from a terminal session, doing an "open" on my link truncates the hash, but if I copy the link into a browser if works fine -- same thing happens if I use a PDF instead of an HTML file. Same thing happens in Windows for both the PDF and HTML files -- very perplexing. I've tried opening a new dialog with a webView to display the HTML -- that does work with the location hash -- but when I close the dialog my application crashes. This might be related to the fact that my dialog (actually any dialog I use including a QMessageBox) is executed following an event filter capture for a QWhatsThisClickedEvent, but I haven't been able to get an answer on that, either.

Thanks!

Kodi

The file: scheme URL is ultimately converted to a file path using QUrl::toLocalFile() in the QDesktopServices code, and it is this that strips the fragment identifier (which is defined for the http scheme but not file). If you paste the same file: URL into the Windows run box you get the same result, so even if Qt did not do this, Windows would.

You could try installing your own URL handler (see QDesktopServices::setUrlHandler()) and use it to launch a browser directly. Then, for example, the URL local://path/to/file#fragment can do anything you like in response to openUrl().

So then I can't rely on the default handler -- my help document is originally a PDF but when I couldn't get the "#page=20" to work I converted it to HTML. Last night I was reading up on the QDesktopServices::setUrlHandler() and thinking that might be the way to go so thanks for confirming.

Your first paragraph is exactly what I saw when I was testing.

Thanks!

Kodi

Hi,

I'm very interesting by what you try to do.
Are you succed to open pdf file with #page=X extension using "QDesktopServices::setUrlHandler() ?