Have you checked our Audit functions? (see
Documentation and
introduction tutorial)
If you import a lot of records in a database, the Audit function can slow down the import process a lot. Because for each field, Filemaker triggers the plugin and we record all the changes while importing. This is not necessary. So when import and you see this dialog, please make sure the checkbox is not marked:
Now you import and the plugin does not record changes while importing, so it's very fast.
To inform the plugin about your changes and to log them, you now loop over the imported records and call the
Audit.Changed function for each record. You can easily find the imported records by checking the AuditState field as it has no value. Use a Set Field script step to set the AuditState field with the result to calling
Audit.Changed with the same parameters as in your table definition.
Now the plugin has all entries logged, so it can keep history and you have old values on changes for a later undo/restore operation.
With our
2.9pr1 plugin we included the Filemaker Runtime Shrinker for Mac OS X. Download it on our
prerelease plugin download page. This is a little tool which can shrink your Filemaker runtimes significantly.
The main window looks like this:
Left Filemaker 11, right Filemaker 12.
As you see we have 4 options:
- First you can remove PPC code. As Filemaker does not even run on PowerPC based Macs, you can safely remove the old PPC code. It's not needed and we are not sure why Filemaker actually does include it in the first place.
- Second, we remove duplicate libraries. Yes, the runtime contains a few shared libraries several times and it works fine if you remove the duplicates.
- Third, there are some icon files in the runtime which are not assigned to file types, so the operation system will never use them. You can remove them easily with this option.
- Finally you can reduce the number of languages you support.
When we click the shrink button with all options and leaving only one language, we get the runtime smaller and the result dialog:
As you see we save 95 MB (64%) for a Filemaker 11 runtime here and 85 MB (55%) for a Filemaker 12 runtime.
We already had questions for a Windows version. Filemaker runtimes on Windows include a lot of DLLs and all are required as far as we see. You still can yourself delete some localization files if you like. Also you don't need to include the Microsoft Runtime folders on Windows 7 as far as we see. Those libraries do ship with Windows 7, but please test that yourself.
Please give it a try and if you have questions, please do not hesitate to ask us.
if you want to share this news with friends, please point them to our website/blog so they can download the latest version. This app will probably need updates regularly for newer versions of Filemaker. And I hope Filemaker Inc is not upset with us providing this tool.
With the last
Filemaker Magazine they included an article from me about how to use
file dialog functions from MBS plugin.
With a little image database, we import images and batch export them later. With the plugin you can define initial folder or customize the dialog with different captions or titles. Also you can ask the user for file, folder or even both.
The article is in german and currently we have no translation to english.
Download PDF:
fmm_201203_30-31.pdf
Just two months left until the great conference takes off!
Your chance to meet over 100 filemaker developers from Europe. Also you can meet people from Filemaker, Inc and of course you can talk to me and learn about our plugin.
For more details, please check the
filemaker-konferenz.de website.
With the coupon code "mbsplugin", you get a 10 Euro discount on the conference ticket.
Nickenich, Germany - MonkeyBread Software today is pleased to announce MBS FileMaker Plugin 2.8 for Mac OS X or Windows, the latest update to their product that is easily the most powerful plugin currently available for FileMaker Pro. As the leading database management solution for Windows, Mac, and the web, the FileMaker Pro Integrated Development Environment supports a plugin architecture that can easily extend the feature set of the application. MBS FileMaker Plugin 2.8 has been updated for Filemaker 12 and now includes 1100 different functions, and the versatile plugin has gained more than 100 new features:
With our new
Audit functions you can log all changes on a database in a log table. This way you always know who edited what value in what table. And you can restore the old state if needed. On normal workflow the performance cost is not noticeable.
For Mac OS X 10.8 you can now
send notifications to the new notification center. For example for reminders or to report status for background activity. With a runtime you can have your runtime launched when the notification was clicked. And if your solution is running, you can receive a script call when the notification was shown to your user.
New
RemoteControl functions allow you to move the mouse programmatically and press the mouse buttons. Also you can press keys and on Windows enumerate all windows on the system. This functions can help you scripting other applications.
New
file functions allow you to copy, move and rename files and folders. Of course you can also move files/folders to the trash. And using Files.List function you learn what files and folders exist in a given folder.
Read about all changes in detail in the
release notes on our website. Please also take time to check our more than 100 example databases showing you the functionality of our plugin.
The
Filemaker Magazine (in German) published a new issue today and it features an article from me about our
MBS Filemaker plugin.
Included is an article from us about using our MBS Plugin to show
file dialogs. First we show you how to select a file using the plugin and importing it. Than we show you how to select a folder for export and export all images in a table into the folder.
If you have questions, please do not hesitate to ask us.
Also if you have time to come to Austria in October, don't miss the
Filemaker conference in Salzburg. 11th to 13th October 2012.
Sometimes people want to know who edited which record when and what values changed. All this questions can be solved with an audit log and our plugins. The idea is simple: Whenever someone changes something, we write a records for those changes to the AuditLog. Later you can check the log or have a script restore the changes.
The
MBS Filemaker Plugin 2.8 introduces a few new
Audit functions.
To show you how it works, we add Audit Logging to one of the starter solutions, the Event Management database. First we go and create a new table named AuditLog. This table can be in a different database file if needed as long as the plugin can find a table with that name. But in all cases, we need you to have a layout for the AuditLog table. It's not required to be user visible, but the plugin needs to find it.
Next we create a couple of fields. Required for the plugin are FieldName, FieldHash, TableName, RecordID. So we can store which table and which field changed. RecordID is the unique ID of the record and FieldHash stores a hash value for the content of the field. Optionally you can add more fields: FieldValue, FieldOldValue, FieldType, UserName, IP, CurrentTimestamp, TimeStamp, CurrentTime, CurrentDate, Action, CurrentHostTimeStamp, PrivilegeSetName, AccountName, LayoutNumber, ApplicationVersion, FileName, HostApplicationVersion, HostName, HostIPAddress, LayoutName, PageNumber, LayoutTableName, TableID, FieldID and WindowName. In this example we added FieldValue and FieldOldValue, so we know the new and old values for the change. The action field stores what happened and FieldType can tell us what data type we have for the value.
You can later add more fields if you like. The plugin dynamically detects them and fills them with values. Like if you need to know the IP of the user, simply add a new IP field and all new log entries record the IP addresses.
Now we can check all the tables in the database. For each we create two fields. First AuditTimeStamp with the timestamp when record was last modified. And second the AuditState calculated field which calls our plugin. The fields do not need to have exact this names. But if you don't use the default names, you have to change them everywhere and inform the plugin.
Here you see the definition for the time stamp field. We check the checkbox to store here the record modification timestamp. Filemaker will update this field automatically every time the record changes.
We typically do not allow the user to edit the Audit fields.
We define the AuditState field. Simply a text field which is calculated. Also make sure the checkbox "Do not replace existing value of field (if any)" is unchecked.
Here we also declare that user should not edit the field.
In the calculation for the AuditState field, we call the plugin: MBS( "
Audit.Changed"; AuditTimeStamp; "Contacts" ). As you see we call the
Audit.Changed function and pass the time stamp field from above. Third parameter is the name of the table. Filemaker simply does not tell the plugin what name the current table has, so we need to pass it here. If the table contains fields which you don't want to be logged or you have given AuditState/AuditTimeStamp fields a different name, you should pass them here as additional parameters. So for example you can call MBS( "
Audit.Changed"; AuditTimeStamp; "Contacts"; "myAuditState"; "myTimeStamp"; "internalField" ). This way the plugin will not log those three fields. Unstored calculations and global fields are never logged. With the function
Audit.SetIgnoredFieldNames you can globally define which fields you want to ignore always.
When all tables have been prepared, you can use the database. As you see, the first time the plugin sees a record, it writes log entries with "Create" as action. Next time you touch the record, you see "Change" entries for all the changes you made.
You can later add more fields to be logged like UserName or WindowName.
With
Audit.Delete function you can also log deletion of records. But that is a topic for another blog entry.
If you have questions, please do not hesitate to contact us.
(more)
To show you how it works, we add Audit Logging to one of the starter solutions, the Event Management database. First we go and create a new table named AuditLog. This table can be in a different database file if needed as long as the plugin can find a table with that name. But in all cases, we need you to have a layout for the AuditLog table. It's not required to be user visible, but the plugin needs to find it. 
Next we create a couple of fields. Required for the plugin are FieldName, FieldHash, TableName, RecordID. So we can store which table and which field changed. RecordID is the unique ID of the record and FieldHash stores a hash value for the content of the field. Optionally you can add more fields: FieldValue, FieldOldValue, FieldType, UserName, IP, CurrentTimestamp, TimeStamp, CurrentTime, CurrentDate, Action, CurrentHostTimeStamp, PrivilegeSetName, AccountName, LayoutNumber, ApplicationVersion, FileName, HostApplicationVersion, HostName, HostIPAddress, LayoutName, PageNumber, LayoutTableName, TableID, FieldID and WindowName. In this example we added FieldValue and FieldOldValue, so we know the new and old values for the change. The action field stores what happened and FieldType can tell us what data type we have for the value. 
Now we can check all the tables in the database. For each we create two fields. First AuditTimeStamp with the timestamp when record was last modified. And second the AuditState calculated field which calls our plugin. The fields do not need to have exact this names. But if you don't use the default names, you have to change them everywhere and inform the plugin.
Here you see the definition for the time stamp field. We check the checkbox to store here the record modification timestamp. Filemaker will update this field automatically every time the record changes. 
We define the AuditState field. Simply a text field which is calculated. Also make sure the checkbox "Do not replace existing value of field (if any)" is unchecked.
In the calculation for the AuditState field, we call the plugin: MBS( "Audit.Changed"; AuditTimeStamp; "Contacts" ). As you see we call the Audit.Changed function and pass the time stamp field from above. Third parameter is the name of the table. Filemaker simply does not tell the plugin what name the current table has, so we need to pass it here. If the table contains fields which you don't want to be logged or you have given AuditState/AuditTimeStamp fields a different name, you should pass them here as additional parameters. So for example you can call MBS( "Audit.Changed"; AuditTimeStamp; "Contacts"; "myAuditState"; "myTimeStamp"; "internalField" ). This way the plugin will not log those three fields. Unstored calculations and global fields are never logged. With the function Audit.SetIgnoredFieldNames you can globally define which fields you want to ignore always.
When all tables have been prepared, you can use the database. As you see, the first time the plugin sees a record, it writes log entries with "Create" as action. Next time you touch the record, you see "Change" entries for all the changes you made.