In a web viewer a html file is displayed. Having a list of topics with topic id in a portal, I want to programmatically scroll to the corresponding id tag in the html. How does the URL look like for scrolling to a html tag in web viewer?
1. Le fichier HTML doit avoir des références <a> contenant les ID.
2. L’appel HTML pointe vers l’élément <a> du fichier HTML.
~David Lalonde
HTML file must contain <a> references containing the IDs
HTML CALL must point towards the <a> tag
1 Like
The web viewer loads the page. This is what I get right. It just does not jump to tags and always shows the top of the page.
Here’s the call:
Set Web Viewer [ Object Name: “Viewer” , URL: table::html & “#href=” & $TagID ]
David says it’s hard to tell without having seen the html
Here’s a screenshot that shows some the <a> tags of the concerned html. Hope this provides enough information. Thanks for looking into this!
Hello @Torsten
I would try setting the URL to nearly (but not quite) what you have:
I suggest keeping the “#” character, but leave out “href=”.
Doing so would be in keeping with how the hash tag (#) is normally used in the context of URLs and anchors within the page.
You might even try it in a web browser to compare – it should work there, as well.
Kind regards and hope this may help.
-steve
2 Likes
Hi @steve_ssh,
thanks a lot for chiming in.
URL “file:///Users/torsten/Desktop/145%20XML.html#_DxCrossRefBm9000015” works in web viewer.
The same URL fed into “Open URL” opens the file in the browser but arrives there as “file:///Users/torsten/Desktop/145%20XML.html”. The hashtag part somehow gets lost on its way to the browser. Adding the hashtag part manually in the browser’s URL line makes it jump to the right place in the html when hitting reload.
This saved my day. Thanks!
Best regards
Torsten
2 Likes
This is great to hear, and as I both hoped and expected.
I must admit, though, I was caught off guard by Open URL not passing the hash tag value along.
Thanks for posting back with the results.
Kind regards,
-steve
3 Likes
In Open url, the hashtag is a reserved character so it might need to be encoded?
I tried that, but to no avail.
Yeah… David just confirmed that the encoding doesn’t yield the expected results. He got the itch though so he’s trying to figure out what makes FileMaker drop it now.
1 Like
Excellent, I gave up last night at 3 p.m., to tired. Still have no idea why this does not work.
Curious to read what David will find out.
In case it helps provoke some thoughts about this:
On MacOS:
The chain of events when using the Open URL script step may not be:
FMPA --> Web Browser
But rather I believe it is something more like:
FMPA --> Operating System service --> Web Browser
That is:
There is an intermediate connection which may not be immediately apparent, which is that FMP is not directly talking to the web browser to launch the URL.
Instead, I believe it hands off the URL to something at the system level which is designed to field the URL, determine the best (or configured) application appropriate to hand off the URL, and the dispatch the message (and URL) to that application accordingly.
(I should mention that my machine is still on High Sierra, so, if this has changed since, I would be unaware.)
I raise the point about an intermediate step because it is one more link in the chain between FMPA and the web page rendering in the browser, and hence one more place where the hash tag could be dropped.
And, in fact, I suspect that this intermediate link may be where the hash tag is being dropped.
To semi-illustrate some of the above (again, on MacOS, HS):
- In the Finder, use Get Info on the target HTML file to change the application that is designated to open it.
(For instance: Specify that a different browser, or a text editor should be used to open the file.)
My observation: Open URL within FileMaker will follow the specified behavior, and the specified target application will be used.
-
Try using the open command in the Terminal application to open the target URL:
open file:///Users/torsten/Desktop/145%20XML.html#_DxCrossRefBm9000015
Again, I observe that the application used to open the file matches that which has been set using Get Info.
Also: I note that the hash tag is dropped when using the open command in the Terminal.
To be fair/clear:
I don’t recall seeing any documentation explicitly stating that FMPA dispatches the Open URL script step to an underlying OS command equivalent to using open in the Terminal, but I do believe this to be the case.
The above observations do not prove this to be so, but it certainly would make a lot of sense for it to be true.
And, if it is true, since it looks as though the Terminal command drops the hash, I think there is a good chance that this explains why the hash is dropped when using Open URL.
Hope this helps, or is of interest,
Sincerely,
-steve
EDIT: On MacOs it’s probably being handled with this:
Launch Services | Apple Developer Documentation
2 Likes
Thanks, @steve_ssh. This sounds plausible. I observed the same some years ago on iOS when working on a WD solution. Whatever was added to the URL (#something) was cut off once the URL was stored as a bookmark in Safari.
1 Like
I’d like to point that you could also use WebView.RunJavaScript in MBS FileMaker Plugin to scroll in Javascript or scroll directly with WebView.Scrollbar.set function.
1 Like
Thanks for the hint, @MonkeybreadSoftware. I’ll try the .RunJavaScript when more versatile access to html content will be required.
Can you corroborate @steve_ssh’s observation above?
If it is indeed this, could one force FM to rebuild the URL from a JSON so it would not try to manipulate the url ?
Hello @Cecile
I’d like to understand better what you are saying – I did not quite follow your suggestion.
I’ll mention, in case it helps, that my understanding was that things are working ok for @Torsten in the webviewer. I was under the impression that the pursuit of an explanation for the behavior with the Open URL script step was more of an academic point.
With respect to having an external browser load URL auto-scrolled to a specific position, the only solutions I currently see would involve having FMPA not only prompt the load of the URL, but also generate the very file that is to be opened. Perhaps this is the same, or similar to what you are suggesting?
Kind regards,
-steve