I'd like to allow webDirect users who are on mobile phones to be able to call the phone number being displayed on screen. How do we do this nowadays?
I've tried a number of different methods:
Display field on screen, locked
Display field on screen, unlocked
Display merge text on screen
Display merge text on screen with "tel:" prefix
Display calculated text in a button label
Use Open URL script step.
Use Web Viewer with a calculated data URI
I had really hoped that the browsers would auto-sense the telephone number, which is what I was looking for in the first five methods.
The Open URL and the Web Viewer both create a link with "<a href="tel:12345678">call 13245678</a>". In Android and in iOS the link generates a new window, which triggers this warning.
I could put up with that if the call was made, but clicking Allow does not result in a call being made. It simply displays a blank window (hiding my app). It's very user unfriendly and it does nothing.
If you try googling "FileMaker WebDirect" mobile dial phone, you'll find quite a few community threads about this exact thing. Consensus is it is doable via web viewer producing the link instead of open URL
I have been generating a link in a web browser. I was getting a warning about pop-up windows being opened in both android and ios. After allowing the pop-up window the TEL link was not opened in the phone app. However, the link that @jkoester has posted includes some extra elements. It uses an alt tag, which apparently is important (???) and targets "_parent". I'll add those extra elements and see what happens.
I'll try it out. Originally I was using the data URI to publish snippets. Currently I am using a complete page, including a head section so I can include meta tags.
I'm still trouble-shooting. Today I was trying to resolve a problem on android. If I clicked the TEL link it would dial the number but going back to the web browser was problematic. The socket to the page is being disconnected forcing the user to reload the page and re-login.
I definitely experience some inconsistencies (of various types) when interacting with different devices/platforms/FM vs Go, etc. Sometimes things work perfectly, and sometimes I'm left scratching my head and using trial and error to sort stuff out. (Nothing new, I guess.)
E.g. I have a little app for use on iPhone (FM Go) which involves an animated .gif. The .gif shows when an On Timer script is running (actually a series of scripts). Works perfectly on FMP, worked first time on Go, then no longer animates at all. Replaced the file, added refresh window steps, pause, etc. and it never animated again. I may place it in a Web Viewer, but then there'll be that brief white flash (unless I move it to an area of white background). Still tinkering.
#2 E.g. GetContainerAttribute ( "myTextTarget" ; "content" ) used to grab text within a text object if named, at least back in v16ish (even though it's not listed in the attribute options lists). Now it just presents a "?" so I must refactor the "widget" that uses this and replace my simple text object (which includes some html and a merge field for Base64 data) with a calculation field and construct the text for output. Not a bit deal, but FM doesn't like some of the characters needed (can't escape them) so will need to add Char function for Unicode/ASCII values to the calculated string. LOL I'll probably live, but "content" was soooo easy.
In my web viewer I'm using "data:text/html," & GetLayoutObjectAttribute ( "DialPhoneCode" ; "content" ) . The web code is in a text object that is stored off-screen. Works perfectly. Have you mixed up your "Container" with "LayoutObject"?
What I'm finding odd at the moment is that (before I added your code) I solved the blank page on Android issue. The web viewer is currently using a simple link;
HA!! It is a text layout object!! (as mentioned "text object"). I had been working with some containers and rushing through this little personal project and copied some work from another, older solution. Sigh. I'm glad I added it to my ramble above, so that you caught it and posted back. My brain didn't notice that I had allowed the wrong function in the copied script. ::shameOnMe::
Sometimes, burning the candle from both ends (or jumping in and out projects with distractions) has consequences. Thanks again, Malcolm.