I was wondering if anyone had an example of how to use MBS to play audio files from a container field. The example I'm ideally looking for would have VCR type buttons for play, pause, and at least a way to "rewind" the audio file a second or two.
I've looked also at the Web Viewer but there seem to be issues using that with Web Direct for audio file playback.
Maybe there's an entirely better way to play an audio file like a JavaScript plug-in for FileMaker? Haven't seen that yet.
These audio controls must work using:
1. FMP Mac (local or running app from FMS) 2. FMP Windows (local or running app from FMS) 3. FMS Web Direct
Just a note that, IIRC, on the old forum, @jeremyb once helped someone out by posting an example of an audio player within a webviewer. I believe that this would have been well over a year ago. It might be worth either reaching out to Jeremy, or searching for that post, to see what library and/or technique he used, and whether or not it could meet all of the platform requirements for your project.
A couple of things are catching my eye as potential issues here:
I see data:type="audio/mpeg", but really the data type is still "text/html" if the payload is still an html webpage. (Even if that webpage contains some audio, it is still an html page.)
The javascript that you show is referencing a variable named $$AudioFile. This looks as though you may be expecting the javascript code to be able to reference variables defined outside of the webviewer, in the FileMaker environment. The webviewer javascript can not see or access such variables on its own accord.
Two common approaches for this type of thing:
1) More contemporary, v.19 approach:
Define a function in your javascript code that can receive a string of Base64 data as a parameter, and which will then use that string to initialize your audio player.
Use the Perform JavaScript in WebViewer script step to call the above function, supplying the relevant base 64 string.
2) Common approach prior to v.19, and still perfectly good approach:
Create the entire HTML page code within FileMaker (using calcs and scripting), and then set the webviewer to use this calculated HTML code.
I note that this is already the direction you have taken (or very similar).
The thing that you would need to do differently would be to literally embed your entire Base64 string into the HTML that you compose within FMP -- not just a variable reference such as $$AudioFile, but rather the entire Base64 string. I'll often just include a var, const, or let statement to declare a variable, and set the value to the Base64 string.
Note that, above, I used an RFC number which does not include line-breaks in the encoded output.
Additional thoughts:
Because you were able to get it working in a standalone html file, I think you are really close to getting this to work in a webviewer in a basic FMP client situation.
If the above isn't clear enough, and you can share some excerpt of what you have working in a standalone page, I'd be happy to see if I could make a suggestion based on what you are able to share.
I see an unclosed quote in the line within the function, on the line where x is set.
My suggestion:
Once again, work to get the above working standalone in a browser. When you get it working in a browser, you will be able to shift to deploying in the webviewer as you have described above, by using Perform JavaScript in WebViewer.
Ok - great. I did not realize that you had it working in the browser still. (And smart thinking to put the alert() in place to test the connection.)
Another thought to try out:
Set the HTML into the webviewer
Pause for a couple of seconds
Trigger your script that calls "Perform JavaScript in WebViewer"
I was recently working with a colleague on one of these integrations, and we found that there needed to be enough time to allow the WebViewer to load the content and be ready to receive script invocations from FMP. I can not recall the error code though, i.e. whether it was "5" or something else.
Not sure what you mean by "Set the HTML in the webviewer". I've set it statically. Could that be the problem?
The HTML and JavaScript are in the WebViewer Source which is just a regular text field. I direct the webviewer to the text field for the HTML / JS as you see in the setup dialog above on the right side.
I did a 15 second delay between the first and second script step and also, separately, after the second script step. No change.
If you don't see anything wrong, I'll report an issue as there's no way this should be so difficult and convoluted.
That shouldn't be a problem -- setting it statically as a calc should work fine for starters, to get a proof of concept going. I'm going to DM you. Should you want to send me stripped down version of what you've got, I'd be happy to take a look and see if I can spot anything.
Thanks so much. In my case, it was custom HTML/JS that I wrote and needed to get working in WD. Perhaps Jeremy's library would be helpful, but I always try to minimize the moving parts I need to maintain, understand, and ultimately, get working.
Thanks to @steve_ssh 's extremely helpful input and an "ah ha" moment on my part when I just went for a walk to forget about it for a bit, I then got it all working.
