WDCopyToClipboard.fmp12 (208 KB)
Hi, I am not sure is that ok to share the sample file here. If not, I will delete it. I have taken it from the official community.
This sample file is used to copy text from fields to the clipboard in web direct. But I have tested it in safari and chrome, it only works in safari.
Does anyone know the reason why it does not work in chrome?
You’re generated code contains a ‘#’-character, this breaks the iframe in WebD. You can either URLEncode the code or just replace the ‘#’ with ‘%23’, have a look at the attached sample.
best
OtmarWDCopyToClipboardChromeFirefox.fmp12.zip (73.2 KB)
Thank you. It seems that it does not work in Edge and IE?
Yes, no data/text iframes in Edge and IE, you’d have to export the html-code to FMS webroot and link it from there.
Thank you. I am new to web-direct, which folder should I export to? 
If you’re on windows, put it here:
C:\Program Files\FileMaker\FileMaker Server\HTTPServer\conf\yourbutton.html
on macOS:
/Library/FileMaker Server/HTTPServer/htdocs/httpsRoot/yourbutton.html
and the webviewer point to: https://your.webd.url/yourbutton.html (without /fmi/webd…)
Thank you. I will try later.
Hi, I have exported it to html file and I could see it on layout, but how do I run javascript and return the field value back to the clipboard?
You’d have to recreate the html file on every field change or record switch. With the new file script steps of FM(S)18 or BE plugin you can do this with PSOS. To be able to write to the web root folder of FMS, it has to be sym-linked into the DATA/Documents folder.
Attached file has a script that generates the needed command to be executed on the server machine.
best
OtmarWDCopyToClipboardAllBrowser.fmp12.zip (78.0 KB)
Hello @Otmar
It is really great to have your presence here in this forum!
Regarding this particular topic:
Another way that I have handled the case of passing data into a file served from WebD web server root into a WebD webviewer (iframe) is to pass the payload in the URL as either a query-string value or a hash value (I no longer recall which I used). This always worked reliably for me, but I never tested it with browsers on Windows machines. It allowed for the html file in the webserver directory to be static – no need to recreate it at each call. (The file simply must be re-designed to pull its target value from the URL). The only downside that I know of is that it only works reliably with small payloads.
I know that you have super amazing expertise in this area. Aside from length limitations, have you run into any other issues with such an approach?
If you have any thoughts to share about this, I’d love to hear them.
Again - great to see you here.
Kind regards,
-steve
Hi @steve_ssh
Same great to have you around here!
I’ve just recently came up with this way to write to the web-root by trying to get my ResourceCalendar work in WebDirect and Edge/IE, as those don’t support data/text in iframes. To have all the needed variables filled by payload would have been a much bigger task.
The copy button is just an adoption of this, and yes definitely a candidate for the payload approach, as long the to copy field content does not exceed max param length.
best
Otmar
Awesome. Thank you, @Otmar