Queing of calls from FM into the webviewer

[simon0863]

Hi Stephen , firstly thanks for creating this utility , it tidies things up nicely.

I had one question re Filemaker calling scripts in the viewer from the Perform Javascript In Webviewer script step, when a script is called immediately on layout enter.

Will onfmready que these incoming calls to scripts in the browser, or is that just not possible because the filemaker object is still to be injected.

My initial testing suggests onfmready cannot do this, but I could have something wrong in my setup.

Kind regards

Simon

[Stephan Casas]

Hi, Simon. Thank you for your question and for using OnFMReady.

Function calls made from FileMaker/WebDirect → Web Viewer are invoked similarly to the way that they would be if you were calling a function by typing it manually into a browser's developer console. In-fact, if you investigate using Function.prototype.caller or if you write a function which throws an error and then console.log() Error.prototype.stack, you'll see that the caller comes from global code (or your OS browser's equivalent).

What this ultimately means is that there isn't a viable channel to intercept those calls. Very early-on, I was interested in making this work for the purposes of diagnostics/debugging, but it's unfortunately a dead-end for two reasons:

• Calls from FileMaker/WebDirect → WebViewer would need to be sent to a "controller" function/proxy which would then act as a queue worker — performing calls one after another.
• Such a controller would not be immediately available for execution on layout entry, so it would be impossible to determine when FileMaker/WebDirect could reliably make such calls.

OnFMReady flips the OnLayoutEnter logic by suggesting an approach in which the web viewer is only navigated when the user enters the layout — that is, only the web viewer's content is loaded on entry. Then, if it's necessary to send data using a Perform JavaScript in Web Viewer script step, such steps can be placed in another FileMaker script which OnFMReady will then call. This essentially turns the web viewer's "Ready" state into a sort of script trigger on its own, which is where the utility gets its name, "OnFMReady."

Use of a workflow similar to this ensures that all resources will be ready prior to any function calls being executed. With respect to queuing, JavaScript's synchronous lifecycle will take care of that automatically — as only one thing can be done at a time (in the absence of async).

[simon0863]

Thanks very much for this clarification Stephen