Set Variable [$r; Value:MBS( "WebView.SetFormTextAreaValue" ; "MarkDownWebViewer"; "formtest"; "input"; WebViewer MarkDown::Input; 1 )]
Set Field [WebViewer MarkDown::Output; MBS( "WebView.GetFormTextAreaValue" ; "MarkDownWebViewer"; "formtest"; "output"; 1 )]
Set Web Viewer [Object Name: "PreviewWebviewer"; URL: "data:text/html," & WebViewer MarkDown::Output]
As you may know we are big fans of SQLite. So we offer for both Xojo and FileMaker to use SQLite for connecting to database with our SQL functions.
Now we have a SQLite internal library already for some time in Xojo. With next prerelease we add that for FileMaker. So with both tools you can now use MBS SQL functions and use the internal SQLite library. This frees you from providing yourself a dylib/dll file. Currently we use version 220.127.116.11, but can update at any time. If you need a specific extension for SQLite, we can also check if we can enable it by default. Currently we support column metadata, full text search, soundex and thread safety.
Another thing we add with next prerelease is encryption. We licensed the SQLite Encryption Extension and include it now by default. You can use it to access SQLite databases using our plugin with AES 128 OFB, AES 256 OFB and RC4 encryption. The AES 128 mode is the same as in Xojo (or Real Studio).
To enable encryption, please use in FileMaker the SQL.SQLite3.SetKey function after connecting. In Xojo we have SQLiteEncryptionKey properties in both SQLDatabaseMBS and SQLConnectionMBS classes. If you set those, the plugin will apply the key after connecting automatically for you. Alternatively you can use SetKey method in SQLite3MBS class directly.
Interested in testing, please contact us soon to get a copy to try or wait for the next prerelease to be uploaded.
Next I launched the FileMaker Server installer (14v2) and cancelled it after it decompressed. Than I changed the "Assisted Install.txt" file in the Files folder with installation files to have the license key and name already, so I don't need to enter it myself.
In the setup.ini I had to remove below the [ISSetupPrerequisites] section the first four lines for Application Request Routing. I installed this software myself before and FileMaker's installer fails to download it.
To run the installer, I run cmd to open a terminal window. There I use cd to go into the folder and run this command line:
For the next prerelease we add a new DynaPDF function for both FileMaker and Xojo to show differences in two PDF pages.
This is a new function written to annotate a page in a PDF with highlight annotations if two blocks in a the pages have different image. This works well here and shows differences in various PDFs. We include a check to make sure that lines moved up or down on the PDF page don't cause to be highlighted.
Please try soon in next prerelease. You'll need a DynaPDF Pro license as this is based on the render feature.
As you may know our MBS Plugin can read compressed containers for a while. Now with new plugin version we add creation of compressed containers.
Container.Compress compresses an existing container. This way you can loop over records and compress them on the fly. But be aware that a lot of media formats (PDF, images like JPEG and PNG, audio and video files) are already compressed, so compressing them again may increase size! But you can use our Container.GetTotalSize function to check if size after compression is actually smaller.
With the new function Container.Decompress you can decompress containers. This allows you to decompress a container if it's compressed and pass it to a function which doesn't understand compressed containers. To know if a container is compressed, check with Container.GetTypes function if there is a ZLIB data stream in the container.
Our function Files.ReadFile can read a file. In next plugins you can use mode = "compressed" to return the content of a file as a compressed container.
All the compressed container functions work fine on older FileMaker versions like 11 where FileMaker doesn't support it.
As you see here, we build a menu in FileMaker. We go to a separate layout with our menu entries table. There we loop from first to last record and look if the group matches the one we got in script parameter. Than we add this menu entry to the menu for calling the script in the table. This way the user can edit menu by editing the table.
# go to layout with menu entries
Go to Layout [ “REP” (REP Reports) ]
# this script can be called with various groups
Set Variable [ $type ; Value: Get(ScriptParameter) ]
# make a new menu
Set Variable [ $menu ; Value: MBS( "Menu.CreateMenu") ]
# loop over records
Go to Record/Request/Page [ First ]
# if group matches
If [ REP Reports::Group = $type ]
# add new menu item with title from table
Set Variable [ $item ; Value: MBS( "MenuItem.CreateMenuItem"; REP::LabelReport) ]
# define which script to call if menu item is selected
Today we introduce our new XML.Import function for FileMaker. it can be used to import any XML file and create records. It translates any field or attribute to fields in new tables. And if the table is missing, the function creates the tables and add fields.
So when you have a job to get regularly a XML imported into your FileMaker solution, e.g. new zip code list every month, you can use this function. First you copy the import script from our example database and import the file once. This will not just import thousands of records, but also create all the required tables. We recommend to put this in a separate import database file, so all those records don't disturb your normal solution. Now when you have maybe 10 new tables generated by our plugin, you can create layouts to show the records. This way you can verify the data is right.
Next step is to use the data. There are two ways. One can be to just reference the import tables from your other database files for lookups, e.g. to find city name for a zip code. Other way is to have scripts walk over the records to copy the relevant portion of the data into your own tables. The imported xml values are all stuffed in text fields and you may have a lot more fields than you may need. So reducing the data and copying it into your own tables will improve performance for lookup. Feel free to add indexes to the tables as needed.
The import process itself runs asynchronously in the background at idle time. So you call XML.Import once and you get back the number of records it plans to create. Now you loop doing script pauses and checking for status. XML.Import.Status will return you the status. It will be "Working" until the work is done and it switches to "Finished". Using the XML.Import.Todo function you can query the current number and show progress dialog like our example.
All tables have three default fields. _RecordUUID is an unique identifier for the record. _ParentRecordUUID provides a link to the record one level higher in the XML. This can be used to find child/parent records. The _CreationTimeStamp is the creation date, so you can distinguish different imports.
Coming soon with next prerelease. For FileMaker 12 and newer.
PS: We also have FM.InsertRecordTSV function to import tab/return text and SQL functions to copy records from within FileMaker or other SQL database to a FileMaker table.
Today we looked into quick import of records from text. A client has from other application a big block of text with tab/return separated values and wants to import them into records.
Our new function FM.InsertRecordTSV takes a name of a table, file, the fields and the text blob and walks over the text to create new records. Works just fine and is very fast. We'll see what other wishes people have on this topic.