QR Codes

Resources Tips and Techniques
1

I hope that @skywillmott will not mind me posting again here from the original: Claris Community (English) post, but I have found his attached example file for creating QR Codes from within FileMaker without using an external API or plugin very helpful.

Sky's original post included this:

"It uses a WebViewer to run some javascript that creates the QR code, and then triggers a single script in the file which saves the QR code as an image in a container field.

Works pretty well, and easily adapted. Have a poke around it to see what it is doing... the key to it is the single text object hidden off to the right of the layout which holds the html and javascript that gets loaded into the web viewer.

Note that in FileMaker 16 there is a new Extended Privilege option called 'fmurlscript' which needs to be enabled for this to work... You will see this if you go to the File menu, and then Manage -> Security... -> Extended Privileges"

I'd also like to add the comment from the original post that a 'File cannot be opened' error will happen if run from a copy of FileMaker that is not the default version that opens .fmp12 files, which initially caught me out. This is quite normal, we have the same problem on some systems that connect to online credit card portals and the streaming server is running multiple versions of FileMaker (until we get everyone migrated to v19).

We have a situation where a customer is having slowdowns due to the connection to the current QR creation external API, after we abandoned Google's deprecated version. Something to to consider if relying on external API connections and their relative location.

Many thanks to @skywillmott for providing this.

QuickQRCreatorMultiLine.fmp12 (184 KB)

8 Likes
2

Such a valid point Andy - I myself have found myself getting a bit 'carried away' with the external service integration options we now have, but often you have little or no control over those services, be that costs, data compliance issues, or just the syntax of the latest API changing.
Always worth evaluating those points before committing to using an external service.

2 Likes
3

Thanks @JamesG. We love the APIs for integrating into customer’s systems and are currently in the early stages of integrating our CRM system into a hosted phone system. My first question was ‘where are the servers located?’.

However, as we’re usually developing our own CRM for our SaaS delivery to our customers, we try to limit the amount we use external systems as much as possible as we have no control over them in terms of distance, availability or change. Even the job referenced above resulted in cost to the client as Google deprecated their API (as they do frequently), then the alternative was causing performance issues and now we’ve managed to bring this in to the system locally.

I believe I read that after the last FileMaker Pro 19 update this broke some of the links to Connect and we cannot afford the impact of this on our customers’ critical office backend systems.

To our cost, we’ve always found that when a vendor causes problems (such as Microsoft introducing a breaking change to a Windows update), as our clients cannot express their frustration to them, it usually lands on us. The less exposure we have to this the better.

Kind regards
Andy

2 Likes