As you may know Xojo deprecated AbsolutePath a few years ago and removed it in Xojo version 2019r2. Now we have projects ranging from old Real Studio versions to latest Xojo versions. I currently have 12 difference Xojo versions installed, three Real Studio versions and two REALbasic versions. We use the QuickLook plugin from us to have each project show version number in the icon.
Recently we added NativePath to FolderItem class for REALbasic and Real Studio. Newer code using NativePath now compiles even in Real Studio. For projects in Xojo 2019r2 we now add AbsolutePath function for FolderItem, so older code using it can still be built. For some projects we even switch between various versions. For example develop on Windows with Real Studio and just use Xojo for building the 64-bit version.
Of course we know that we should get rid of AbsolutePath. But the problem is in compatibility and in the detail. Older projects put file references as AbsolutePath into documents to find related files. Newer versions of the applications now use NativePath or GetSaveInfo functions. But we still want to read old documents with old paths and resolve them. It would be a support nightmare if clients call support about projects not finding their files.
For MBS Plugin 19.5 we add AbsolutePathMBS to folderItem class for all versions of Xojo and Real Studio. We got NewFolderItemFromAbsolutePathMBS function to resolve the absolute path. This even works fine in MacOS Catalina as far as we see.
Recently a couple of users asked how to access network shares on a FileMaker Server. The built in commands from FileMaker are all limited to documents and temporary directory. But with the MBS FileMaker Plugin (and other plugins) you can access other places on the server.
A common use case is to put a second hard disk on the server, create a backup folder there and have a scheduled script copy over some files regularly from the documents folder to the external hard disk. You may get a permissions errors. But you can simply solve this by explicitly giving right permissions to the folder to make it accessible for FileMaker server scripting process executing plugin functions.
So let's talk about those accounts. There are various accounts used on a FileMaker Server when working with network shares or folders on disks.
The account your script is logged in to the FileMaker Server, e.g. admin account. Or let's say better a limited account named "backup", which may not need to access all tables in all files. You can query this name with Get(AccountName) in your script.
The account the FileMaker server runs on the system. For MacOS this is usually a separate user named fmserver. You can query this name with MBS( "SystemInfo.UserName" ) function.
The account you login to a remote file server to mount the network share. This may just be a normal login name or with a domain controller something like "SRV2012\bob".
The account of the local admin, who logs into the server to see the desktop.
Now the admin on the machine may use his account (4) to login and see the desktop. He can use FileMaker admin console in the browser and use his account on the file server (3) to mount a network share and optionally attach it to a local drive letter, e.g. Z.
If a script running under the account "backup" (1) on the FileMaker server tries to write to the network share, it only has the permissions of the FileMaker Server scripting process (2). Access is denied as the network share is mounted exclusively for the local admin (4).
There are two solutions:
You can mount a network share both on MacOS and Windows to allow access for all users. This can be tricky and there are various tutorials on the web.
You can use MBS Plugin with Files.Mount function to have your script mount the network share itself, do its business and then unmount it via Files.Unmount function.
We do prefer the second way as it's more secure. The network share is only mounted for a short time period and only accessible to the FileMaker server while mounted. Even if someone is using the computer, they may see the drive letter, but not access it.
If you have questions, please do not hesitate to contact us.
For our MBS Xojo Images Plugin we added support for libjpeg-turbo. The new JPEGTurbo plugin part encapsulates the libraries for MacOS, Windows and Linux, all built with SIMD instructions for better performance.
In Xojo the JPEGTurboMBS module provides the API pointer, which you can pass via SetAPI functions in JPEGImporterMBS or JPEGExporterMBS classes. Then the next load or save uses the new functions which work with higher performance.
Speed improvements are notable, but of course depend on your test images and computer configurations. We have seen speed increase by factor 2 to 5 here.
Please try the classes soon and report any feedback you have. Included in 19.5pr7 upload.
Next year in April our company will turn 20 years old.
We'll plan to have a big party here in Germany near our office with over 100 guests.
Invitations are going out this month in several batches.
If you like to join and you miss an invitation, you can contact us and ask whether your invitation got lost.
As people confirm they are coming, we'll add them to the guest list. If we run out of space, we may put people on the wait list.
If you can't make it, please respond soon, so we don't need to contact you again later.
New in this prerelease of version 9.5 of the MBS FileMaker Plugin:
Changed trace functions to log name of script and file if changed from last MBS call.
Changed DLL loading for DynaPDF.Initialize and XL.Initialize functions to look for given DLL path, try 32/64 DLLs. If only file name is given, we look into plugin folder, too. If no file name is given, we try default file name.