One of the great things we can do safely in plugins is to put work in extra preemptive threads. This way your GUI in Xojo stays running responsive while you keep all CPUs in a computer busy. This works by calling the plugin method in a Xojo thread. Now the plugin starts processing on a preemptive thread which can run on another CPU. The plugin function on the xojo thread yields time, so your other xojo threads can do their work. Now in total with 8 xojo threads doing work, you can get 8 CPUs at nearly 100% usage each. And that with a total number of 17 threads running: Your main thread, 8 Xojo threads and 8 threads run by plugin.
Now we recently added functions CipherMBS.ProcessFile, DigestMBS.ProcessFile, MD5DigestMBS.HashFile, SHA1MBS.HashFile, SHA256MBS.HashFile and SHA512MBS.HashFile to process encryption or hashing in background. If you schedule threads correctly, you get the full speed up until hard disk is the bottleneck.
xDev Magazine is having a special one-day sale. On May 26 only, everything on the xDev Store is 20% off with coupon code MEMORIALDAY!
To get the discount, just use the coupon code MEMORIALDAY when placing your order on our store. It's good on any orders of at least $25 (including subscription renewals). But please hurry -- this special offer is only good for the one day!
Please save the date and we'll look for a room.
If you are interested in joining, please email me, so we know how many seats we need.
Meeting will be probably in a beer garden or restaurant somewhere near Vienna.
On Windows you can use WebKit for the htmlviewer. And with next plugin prerelease, we'll add new functions for using Chromium there.
Some functions like getting source code, text or image from browser.
Today a FileMaker developer asked if we can use the tiny URL web service functions to create short URLs from FileMaker.
The answer is yes, we can. Here a sneak peak on the script. The example database will be included with next plugins:
The API is explained here and you can sign up for a developer key here.
The script itself is not that difficult. First we start a new CURL transfer and set a lot of options. This includes setting up a form with the various parameters for the service. Than we perform transfer and show debug and result texts in some fields for debugging. Once we closed transfer, we can parse the result json and get the state and the url. If state is not okay, we show dialog with error, else we got our short URL.
In June, I travel to vienna and I think this is great opportunity to have some parties.
So I plan to organize a FileMaker and a Xojo developer meeting.
I started two surveys to find the best days in the week:
Recently in our FileMaker training day there was an interesting question. If we trigger the plugin function through a script on a server, would that perform the Audit calculations on server? Running it on server would avoid a lot of remote SQL queries and be much better for performance.
So if you like to host database on server and have Audit log being updated from all devices, you can do this steps:
First you create the AuditLog table like usually. You add text fields for FieldName, FieldHash, RecordID, TableName and FieldValue. If you like add more like HostName, FieldOfdValue, Platform, UserName, LayoutName or something from the list in documentation. This table must be in same database.
Next you create two scripts per table to watch. First script calls second script with "Perform Script on Server" script step. This script does not need to wait for the other script to finish.
The second script performs the actual Audit call. For this you only need a script step "Set Variable" with the audit calculation: MBS( "Audit.Changed"; Get(CurrentHostTimestamp); "Projects"). Projects is here the name of the table. You can of course include or exclude fields like normal audit handling. If you like, you can pass some extra details using script parameter and use them in this script to log extra information. For that you can for example pass an extra parameter with "Info|" & Get ( ScriptParameter ) to fill the parameter's value into a field named Info.
To actually get something running, you now define for each layout a trigger which calls the first script. So for the trigger OnRecordCommit you choose the script and FileMaker calls the script. The script than performs the other script on server which does the Audit operation. Performance is great here, even from iPad with FileMaker Go 13. If you like you can also have the script perform when user moves to layout or leaves layout.
Please try it. If it works for you, you should see new audit logs being written from FileMaker Pro, Filemaker Go and WebDirect. In the sample project we log in Info field the answer from Get(SystemPlatform), so we record 4 for web direct, 3 for FileMaker Go and 1 for FileMaker Pro on Mac.
There are differences when doing audit on server. Platform on the server is always ServerScripting. The hostname is of course the name of the server. The user name contains the name of script, the login name and and ID. The host IP and time stamps are of course those from the server, not the client.
A new example project and newer plugin is available tomorrow with the next prerelease.
Due to the FileMaker Developer Conference, I will visit San Antonio end of July.
As there are a lot of Xojo users out there in the area, I'd like to offer to meet for dinner in a restaurant.
In order to define which days are best for the meetings, I have setup doodle surveys:
The May/June 2014 (12.3) issue of xDev Magazine is now available. Here's aquick preview of what's inside:
* Updating Xojo * by Marc Zeedar
If you missed what happend at the Xojo Developers' Conference (XDC) in Las Vegas in March, here's a quick recap of the major news.
* Pretty Print Dialog * by Sam Rowlands
Mac OS includes some nifty tools that allow you to make a much more elaborate print dialog box. Sam shares the code for how to make that happen.
* XDC 2014 * by Marc Zeedar
This is a comprehensive report of XDC in Las Vegas in March -- if you didn't get to go, read this epic report to find out what it was like. Marc shares his experiences, as well as key tips from the sessions he attended, along with plenty of photos.
* App Sandbox Guide * by Sam Rowlands
Apple has instituted security "sandboxing" rules for apps on the Mac App Store, which means your Xojo apps are restricted in what they can do. If you're new to sandboxing, here's a guide to get you out of the sand trap.
Plus columns on class interfaces, threads, RegEx groups, Xojo developer profiles, database design, and much more!