bBox for FileMaker v0.93 Now Available

We are pleased to release bBox version 0.93, including new FileMaker script steps and web viewer functions. bBox is a free utility plug-in to extend FileMaker solutions to easily use code libraries and macOS-based functions from Python, JavaScript, PHP, Ruby, AppleScript, Bash/sh, XPath, and SQLite. Also included is a demo file that has over 210 examples of how you can put bBox functions to work for you.


Bug Fixes:

Fixed for v0.93 is a regression with the bBox_FileRead function when using the “O” option to auto-detect file types. This was responding incorrectly for several image types.

New Script Steps:

Added since v0.90 are 22 script step versions of the bBox functions. These may be more convenient and are relatively self-documenting compared to the function versions. However, FileMaker script steps don’t handle things like optional parameters as well as a variadic function does, so some features are simplified somewhat for their script step versions.

New Web Viewer Functions:

In versions 0.92 and 0.93, several new Web Viewer related functions were added to give easier loading of static content into Web Viewers. Other functions give information on the loading state or current contents of a web viewer. And finally, there’s now a function that allows executing JavaScript using the specified web viewer.

  • bBox_WebViewEstimatedProgress( window; webviewer )
  • bBox_WebViewEvaluateJavaScript( window; webviewer; script {; handlerFileName; handlerScriptName} )
  • bBox_WebViewHistory( window; webviewer; path )
  • bBox_WebViewIsLoading( window; webviewer )
  • bBox_WebViewLoadFile( window; webviewer; path )
  • bBox_WebViewLoadHTML( window; webviewer; HTML {; baseurl} )
  • bBox_WebViewTitle( window; webviewer )

The bBox_WebViewEvaluateJavaScript deserves more detail for several reasons. If you happen to be familiar with previous versions of bBox, you may wonder: how this is different from the existing bBox_JavaScript function? Put in to words, you can say that the bBox_JavaScript function runs “pure” JavaScript, and is largely sandboxed in to only have access the data you explicitly give it. The one major exceptions is that it can use the fm extensions class that bBox adds to interact directly with variables and data in the FileMaker Pro/Server environment.

In contrast, the bBox_WebViewEvaluateJavaScript function, and the web viewer it operates on, are not nearly as constrained in their access, and you can execute JavaScript functions, manipulate objects, and pass in or extract out data. How you pass data between FileMaker and the web viewer is less structured however, and may require a bit more work to use.

Put in to a table, this is roughly shown like so:

Functionality bBox_WebViewEvaluateJavaScript bBox_JavaScript
UI HTML elements in web viewer none
FMP Functions None fm.evaluate, fm.executesql
DOM Functions Yes No
Load Related Content Yes No
Server-side No Yes

For the next version of bBox, I may end up changing the name of the bBox_WebViewEvaluateJavaScript function, as I’m finding the current name a bit too verbose, and I think the intent is clear enough without the “Evaluate” part, so simply bBox_WebViewJavaScript seems sufficient. The name change shouldn’t require any changes to your code, since FileMaker stores calculations using the function ID, not their name.

The current demo file has over 10 Web Viewer related examples. These are all adapted from demos for the previous unreleased version of the plug-in, and they are not ideal in the current implementation. Hopefully in future versions I can rework the UI of the demo file and better tune the examples for the current implementation of the web viewer functions.

Some deep background for those that are interested. These functions originally were part of another plugin I wrote, circa FMP 14, but never publicly released. And in FMP 16, FileMaker Pro switched from using the WebKit Cocoa class to WKWebKit, no doubt in part because Apple has said they are deprecating WebKit and its related classes. This change broke the previous implementations of my functions. There are definitely some nice things about WKWebKit, in particular its better usage of threads, but its macOS implementation does have some deficiencies and broken bits, and some additional challenges from the point of view of a FileMaker plug-in. Especially missed by me is the ability to easily implement a JavaScript class that would call back to code in the plugin.

A fragment of this code looked like so in WebKit implementation:

static const JSStaticFunction fmStaticFunctions[] =
{
    { "run", FM_Run_Script_CB, kJSPropertyAttributeDontDelete | kJSPropertyAttributeReadOnly },
    { "evaluate", FM_Evaluate_CB, kJSPropertyAttributeDontDelete | kJSPropertyAttributeReadOnly },
    { "sql", FM_ExecuteSQL_CB, kJSPropertyAttributeDontDelete | kJSPropertyAttributeReadOnly },
    { NULL, NULL, 0 }
};

static const JSClassDefinition fmClassDef =
{
    0,                     // version
    kJSClassAttributeNone, // attributes
    "fm",                  // className
    NULL,                  // parentClass
    NULL,                  // staticValues
    fmStaticFunctions,     // staticFunctions
    FM_Init_CB,            // initialize
    FM_Destroy_CB,         // finalize
    NULL,                  // hasProperty
    NULL,                  // getProperty
    NULL,                  // setProperty
    NULL,                  // deleteProperty
    NULL,                  // getPropertyNamesg
    NULL,                  // callAsFunction
    FM_Constructor_CB,     // callAsConstructor
    NULL,                  // hasInstance  
    NULL                   // convertToType
};

…

    classDef = JSClassCreate (&fmClassDef);
    assert (classDef != NULL);
    JSObjectRef classObj = JSObjectMake (jsContext, classDef, NULL);
    assert (classObj != NULL);
    JSValueProtect (jsContext, classObj);
    JSObjectSetProperty (jsContext, theGlobal, str, classObj, (kJSPropertyAttributeDontDelete | kJSPropertyAttributeReadOnly), NULL);

There is definitely some trickiness to the code that isn’t obvious here, but it was mostly straightforward and worked well. Also nice is that it works identically if just using JavaScript Core’s JSEvaluateScript function. There is still be the possibility of implementing something similar using WKWebKit, but at the moment I’m not liking the approach I’d need to take for this, and documentation and examples of this sort of thing are difficult to come by.

Download bBox plugin
bBox product page

– Simon

2 thoughts on “bBox for FileMaker v0.93 Now Available

  1. I was hoping this version would allow me to construct a command using Filemaker variables. Is there any way to do this with something like:

    Set Variable [ $tmpHTML; Value:bBox_Curl (“-o/var/tmp/www.” & $itemName & “html”; SSG::website URL) ]

    1. What you are doing can work.

      But in your example you are directing curl to save the the result to a file, even though your intent seems to be to have the HTML returned as a result. The -o option redirects the HTML output to the file instead.

      As a best practice, I would probably want to add a -m10 otherwise curl could wait up to two minutes for a response. After the request, check for an error if the server never responded using bBox_LastError(-1).

      Also, watch for issues with the file name specified (e.g., characters like “/” in name) and also that you are correctly escaping any html entities (e.g., ” “) in your URL path.

      Simon

Leave a Reply