Jump to content

MainSpring

Membres
  • Posts

    69
  • Joined

  • Last visited

    Never

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

MainSpring's Achievements

Newbie

Newbie (1/14)

1

Reputation

  1. Typically, portals in FileMaker are used for showing related data. However, a portal based on the same table as its layout would simply display the current found set. If you made the portal large enough, the layout would appear as a list view- which wouldn’t be very helpful. So, in this blog, we will make the portal smaller and create a powerful layout design, the Master Detail portal. If data requires or if users request […] The post Create a powerful layout design in FileMaker first appeared on MainSpring.Afficher la totalité du billet
  2. This versatile function offers quite a bit of value to any developer’s toolkit. It gives us the ability to interrogate the state of different layout objects (also called introspection) which allows us to make our calculations and scripts smarter. Today we’re going to just focus on a one of the options, the attributeName parameter to take a look at some interesting behavior that could be leveraged as another tool in our developer toolbelt. Parameters objectName – in order to use this function, the object to be interrogated must have a name set in the position tab of the inspector. I prefer to use the naming convention of “objectType.name” for clarity. attributeName – the name of a supported attribute specific to the type of the layout object. Which we are using the “content” for this example. Persistent local variables It’s possible to create local variables without running a script. Here you can see the layout we have some text describing the function: Going into layout mode you can see that these are all merge variables placed on the layout, but they are all local variables which normally only exist as long as a script is executing However, the only script in the file has no set variable steps This is accomplished by utilizing the “Hide object when” calculation in the data tab of the inspector for layout objects in tandem with the content option for the attributeName parameter of the function. Off to the side on this layout we have a text object with a calculation This works because when FileMaker is loading a layout it has to check the hide object when calculation for each layout object to determine if it displays or not. Here we’re using “Evaluate( GetLayoutObjectAttribute ( “text.display” ; “content” ) )” Since we used a let statement to declare local variables as the content of our text object and wrapped it in an evaluate function FileMaker will instantiate the local variables even though no script has been run. Checking the data viewer’s watch tab, you can enter in one of the local variables and see that it contains a value but on the current tab the same variable will not be present. Note that you can also set global variables using this same method. These variables will persist until FileMaker is closed or explicitly removed through a set variable script step or through the watch tab in the dataviewer using something like Let() to set them to “”. Uses One use could be to dynamically alter the text sizes on a layout when the user alters the window size. Assuming we’re using the same technique here we can dynamically set the text size based on the size new window size. Since FileMaker redraws the layout on a window size change the hide object when calculation will be evaluated again and will update the sizes accordingly. I’m excited to hear from you what you think you could do with this. Until then, happy FileMaking! Download the Demo File The post Reviewing the GetLayoutObjectAttribute function in FileMaker first appeared on MainSpring. Afficher la totalité du billet
  3. During agile development in FileMaker, sometimes you may notice an unwanted performance difference after adding a new feature, or display a new field to a layout. In this blog, I’d like to address what I have found to be the most likely culprits of the slow and unwanted Find or Sort dialogs on FileMaker layouts: summary fields and “unstored calculations”. Inside the storage options of the calculation field definition is where developers decide if a calculation is stored or unstored. A checked box here (unstored), means exactly what it says: the data will not be stored and must recalculate every time the field is displayed. This is also how summary fields behave. If a summary field or unstored calculation is displayed on a layout, the data is calculated on record load – which, depending on the complexity of the calculations can cause a noticeable difference for the user when navigating through the records. When talking about solutions, it is unfortunately not as simple as just unchecking that box to create a stored calculation. If your calculation references a related table or a summary field or unstored calculation, you will be prompted with this error: The calculation cannot be stored or indexed because it references a related field, a summary field, an unstored calculation field, or a field with global storage. This error message makes sense based on the definition of a stored calculation. A stored calculation cannot simply reference an unstored calculation or a summary field. To improve the performance of a layout, reduce the amount of unstored data displayed on that layout. To do this we use a concept you may be familiar with, caching. Caching is defined as storing away or hiding for future use. A layout of stored data will load faster than a layout that must calculate its data. In other words, the goal is to get the data from summary fields and unstored calculations into other field types so that your layout does not need to reference any summary fields or unstored calculations. If you have existing data, you will need a script to store the existing calculations data before we set up a method of always storing. Create a text/number/date/etc. field for each calculation, then a script that simply loops through the records setting the new fields with the data of the calculations. Once that’s done, or if you are starting on a file with no data, you will need to set up the functionality to store the data in real time so that users can see and do modifications in real time. Display the new stored fields on the layout where the unstored data was, and don’t allow the fields to be entered by the user in browse mode. Consider a two table file with Work Orders that track Services done. Hopefully this example translates to commonly used calculation data. Assume the Service table has a field called “Total”, which is simply “Rate” x “Hours”. The other table, Work Order would have a “GrandTotal” field that sums the related Service “Total”. With this set up, entering the invoice layout causes FileMaker to evaluate the results of ALL calculations and summary fields – which could really slow things down depending on the amount of records. So, let’s set up some caching – the “Total” calculation in the Service table can be switched to a number field defined with an “Auto Entered Calculated value”. As long as you uncheck the option for “Do not replace existing value of field (if any)”, the data will recalculate whenever the “Rate” or “Hours” data changes. This is a critical step, but you likely will not notice the performance improvements you’re looking for until you make changes to the Work Order table, since that would be the layout/table where related data will be displayed. Changing the “GrandTotal” field of the Work Order table is not as simple as the changes to the Service table. If you simply change the calculation to a number field and define it in auto enter you will notice it does not refresh the way Service “Total” did. This is because it is referencing a related table occurrence. All you need to do here is include an OnObject save script trigger that updates “GrandTotal” ANYWHERE the Service “Rate” or “Hours” can be modified. Also make sure that a similar trigger updating GrandTotal is incorporated anywhere Services can be deleted. Display the new stored fields on the layout and make sure you prevent modification to these fields- FileMaker will no longer automatically prevent them, since they are not calculation or summary fields. Also check to make sure the layout doesn’t include any value list referencing the “unstored” data fields. Hopefully after making these types of changes you will improve performance of record navigation and reporting while maintaining accurate data and a normal user experience. Setting up your database to cache data that would otherwise be an unstored calculation or summary field can reduce the workload of a database, decreasing the odds of a user watching loading bars while using their FileMaker solution. The post Caching data to improve layout performance in FileMaker first appeared on MainSpring. Afficher la totalité du billet
  4. A common feature I like to provide on my FileMaker list view layouts is clickable headers that sort records based on that column. Realistically, you don’t always have the luxury of being in a simple 1 table list view. In this blog, I will walk through a consistent way to dynamically sort related data in portals, using the column headers. I would like to preface this blog by saying this is not a concept I invented. It was taught the concept from a coworker – who learned it from a blog or forum. I still believe I have broken the concept down to its simplest form and can explain the parts and how they work in a way that will easily translate to any custom FileMaker solution. Tables and calculations For the sake of this blog, I have set up a very straightforward demo file, made up of only two tables: Person and Company. We will sort people records inside a portal on a company layout. Inside the portal sort dialog, you don’t have the ability to sort by related tables, so you must create calculations inside the Person table. Managing the data in those calculations will manage which field and which order that the portal will use for sorting. Looking into these four calculations will require an understanding of JSON. Also be aware that there is only a 1 word difference between SortTextAscending and SortTextDescending and the same goes for SortNumericAscending and SortNumericDescending. By providing one of each you should be able to rebuild these calculations and make the fields specific to your data. Notice that SortTextAscending and SortTextDescending take only The script The main purpose of your script is to manage a single global variable that is referenced in the four sorting calculations, in this example $$PersonSort. You will also need a simple custom function I use to point to field names rather than field values, called GetFieldNameOnly. We will use this in parameter passing and it will allow us to use the same script for every column used in sorting. The global variable needed is a 2-key JSON object that will manage the Sort’s: 1. ”field” – The custom function points to field name only. 2. “order” – Either “Ascending” or “Descending” The same script can be applied to every column header button. The only difference will be the parameter, which will be GetFieldName ( Table::FieldYouWantSorted ). You don’t need to specify Order in the parameter, the script will default to Ascending order, and automatically alternate on double clicks. This provides a professional look and feel that is sure to please users. So essentially, the purpose of the script is to set the 2 keys of the JSON object and the purpose of the calculations is to read the JSON object. Visuals If you’re willing to go the extra mile, you can layer 3 different buttons with hide conditions. Buttons will need to be named and have script triggers to refresh since they are dependent on a $$GlobalVariable, but in my opinion the extra work is worth it. Sort order icons provide a totally professional look. The 3 different buttons needed will be: 1. An Up arrow for Ascending Order 2. A Down arrow for Descending Order 3. No arrow for when a different field is being sorted. In my experience, users will either be super excited when you add a portal sort feature OR they have no reaction at all because they’re so accustomed to professional UI’s and websites that a feature like that is subconsciously expected. In either of those scenarios, it is a useful FileMaker development tool to have in your arsenal. It is a frequent situation and request, that I once struggled with until, I found some consistency in my approach. I hope this blog was helpful. The post Sorting portals dynamically using FileMaker first appeared on MainSpring. Afficher la totalité du billet
  5. Overview of when it would be beneficial to use abstraction in FileMaker Sometimes you can benefit from a method called abstraction where you use what’s called “indirection.” Indirection is a way that you can automatically iterate through a series of steps like set variable or set field. For instance, let’s say you needed to bring the contents of one set of fields in a table and create new related records in another, a process very common when dealing with legacy app data after importing it into a new app. Here there may be quite a few fields. In this particular instance there happened to be about 40 and it’d be quite the pain to go through and manually copy the same block of script steps in order to create the new related records in order to set the fields, but if you look at the variable naming that is being done for each field set you can see that it follows a pattern of $document, $documentName and $documentNote followed by a number. Since it follows a known pattern like that, we can simply use a count in a variable to use the same loop to set all three fields which in this case looked like this: Using the Evaluate() function we can ascertain whether or not there’s even a value in the $document variable by using a combination of $document & $count as the parameter. So, for the first time the loop runs we’re looking at the contents of $document1. The second time it’s $document2 and so on. So, once we’ve determined that we have a value in the $document variable we proceed to create a record and set the fields using the same technique of Evaluate() and their respective corresponding variable names. It sure beats writing out or copying then tweaking 40 blocks of set field AND saves us a bunch of time to boot! In what ways have you used abstraction or indirection in your apps? The post When to think about abstraction first appeared on MainSpring. Afficher la totalité du billet
  6. Choosing the Name From exporting data to excel sheets to custom print layouts, automated naming for exported files can help with organization and create a more professional look. The first thing to consider when scripting to automate file naming would be to determine a field that makes the record or set of records unique. For single records, it will most likely be a user facing identification field such as, Job Number, Serial Number, or perhaps Username and Job Title as long as it’s unique. For scripts that print a set of multiple records, you’ll typically name the file based off what makes that group unique- maybe Region or State, or often the date or timestamp the export was performed. Naming using a Field As I mentioned earlier, in order to prevent FileMaker from attempting to save multiple files as the same name, you will need to include a field with unique data in the filename. Sometimes this will be easy and natural. For example, if you’re printing single Work Order records and they have a field such as Work Order Number that is defined to have user friendly unique data, you will be safe to save files to a single folder and will be able to have a direct correlation to Files and records. Since no two records can have the same Inspection Number, the only overwriting that can take place would be over an older version of the same record. If there is no visually pleasant identification field (Work Order Number, Job Number, Case Number…), OR you want the ability to save historical/multiple files per single record; then you will probably want to include a date or even timestamp with a not necessarily unique field such as last name or company name. Example: ContactInfo_RyanMcTeer_8_18_2020.xlsx Be careful though, several characters inside of a timestamp will cause errors if you try to save them within the file name. Getting the filename to print as it did in the example will take some scripting. Naming using a Date or Range The characters inside of a timestamp will cause errors are colons, spaces, and slashes. Make sure you use a Substitute function to remove those characters, as I’ve shown in the data viewer below. Using a timestamp in the file name may seem unduly lengthy, but it does guarantee unique file names, and will be easy to organize and navigate through. Also, sometimes the date or time range is part of the data. Perhaps you have a reporting script that asks the user for a time range, then prints or exports all the records that fit that criteria. In a situation like that, you would want the date range in the file name. Shown below is an example of how I would do that, using just dates instead of timestamps. Locations Provided by FileMaker Sometimes clients will specify the location they want exported files saved to. When they don’t specify, I typically export to the Temporary Path, and select the setting to automatically open the file. That way the user will be reminded to save the file wherever they want, every time a file is exported. An example of saving a PDF to the temporary path is shown below: In this example, the $FileName variable must end with the “.pdf” extension, but we will get to File Naming later. Other options as far as export locations would involve replacing the “Get (TemporaryPath)” inside the $filePath variable. FileMaker provides the option of using the built-in function, “Get (DesktopPath)” which is obviously just as fast and easy, but most users are not going to want to clutter their desktop by saving files to it regularly. Custom Locations Other paths will need to be manually constructed, which you can learn about in the FM Help Documentation. It is important to notice, when manually constructing file paths, the path will be different across different operating systems, and your script will need to check the results of Get (SystemPlatform) and construct the path accordingly. This option takes significantly more time and effort than using the two FileMaker provided paths (desktop & temporary). One common location that clients ask for that is not provided by FileMaker would be the Downloads folder. To save time and effort, I reuse a custom function: Let([ docpath = Get ( DocumentsPath ) ; c1 = If ( Right ( docpath ; 1 ) = "/" ; 1 ; 0 ) ; slashcount = PatternCount ( docpath ; "/" ) ; adj1 = If ( c1 = 1 ; Position ( docpath ; "/" ; 1 ; slashcount - 1 ) ; Position ( docpath ; "/" ; 1 ; slashcount ) ) ; trim = Left ( docpath ; adj1 - 1 ) ]; Case ( c1 = 1 ; trim & "/Downloads/" ; c1 = 0 ; trim & "/Downloads" ; "0" ) ) What’s nice about using this custom function is it will point to the Downloads folder on both Mac OS X and Windows, and you can refer to it just as easily as the TemporaryPath or DesktopPath. Instead of setting the $filePath variable to Get (TemporaryPath), you can set it as “DownloadsFolder” or whatever you name the custom function. Using these techniques, you should be able to spend a bit more extra time on your printing and exporting scripts, but gain all the benefits of files saving to the destination you want, with the file names you want. Afficher la totalité du billet
  7. Choosing the Name From exporting data to excel sheets to custom print layouts, automated naming for exported files can help with organization and create a more professional look. The first thing to consider when scripting to automate file naming would be to determine a field that makes the record or set of records unique. For single records, it will most likely be a user facing identification field such as, Job Number, Serial Number, or perhaps Username and Job Title as long as it’s unique. For scripts that print a set of multiple records, you’ll typically name the file based off what makes that group unique- maybe Region or State, or often the date or timestamp the export was performed. Naming using a Field As I mentioned earlier, in order to prevent FileMaker from attempting to save multiple files as the same name, you will need to include a field with unique data in the filename. Sometimes this will be easy and natural. For example, if you’re printing single Work Order records and they have a field such as Work Order Number that is defined to have user friendly unique data, you will be safe to save files to a single folder and will be able to have a direct correlation to Files and records. Since no two records can have the same Inspection Number, the only overwriting that can take place would be over an older version of the same record. If there is no visually pleasant identification field (Work Order Number, Job Number, Case Number…), OR you want the ability to save historical/multiple files per single record; then you will probably want to include a date or even timestamp with a not necessarily unique field such as last name or company name. Example: ContactInfo_RyanMcTeer_8_18_2020.xlsx Be careful though, several characters inside of a timestamp will cause errors if you try to save them within the file name. Getting the filename to print as it did in the example will take some scripting. Naming using a Date or Range The characters inside of a timestamp will cause errors are colons, spaces, and slashes. Make sure you use a Substitute function to remove those characters, as I’ve shown in the data viewer below. Using a timestamp in the file name may seem unduly lengthy, but it does guarantee unique file names, and will be easy to organize and navigate through. Also, sometimes the date or time range is part of the data. Perhaps you have a reporting script that asks the user for a time range, then prints or exports all the records that fit that criteria. In a situation like that, you would want the date range in the file name. Shown below is an example of how I would do that, using just dates instead of timestamps. Locations Provided by FileMaker Sometimes clients will specify the location they want exported files saved to. When they don’t specify, I typically export to the Temporary Path, and select the setting to automatically open the file. That way the user will be reminded to save the file wherever they want, every time a file is exported. An example of saving a PDF to the temporary path is shown below: In this example, the $FileName variable must end with the “.pdf” extension, but we will get to File Naming later. Other options as far as export locations would involve replacing the “Get (TemporaryPath)” inside the $filePath variable. FileMaker provides the option of using the built-in function, “Get (DesktopPath)” which is obviously just as fast and easy, but most users are not going to want to clutter their desktop by saving files to it regularly. Custom Locations Other paths will need to be manually constructed, which you can learn about in the FM Help Documentation. It is important to notice, when manually constructing file paths, the path will be different across different operating systems, and your script will need to check the results of Get (SystemPlatform) and construct the path accordingly. This option takes significantly more time and effort than using the two FileMaker provided paths (desktop & temporary). One common location that clients ask for that is not provided by FileMaker would be the Downloads folder. To save time and effort, I reuse a custom function: Let([ docpath = Get ( DocumentsPath ) ; c1 = If ( Right ( docpath ; 1 ) = "/" ; 1 ; 0 ) ; slashcount = PatternCount ( docpath ; "/" ) ; adj1 = If ( c1 = 1 ; Position ( docpath ; "/" ; 1 ; slashcount - 1 ) ; Position ( docpath ; "/" ; 1 ; slashcount ) ) ; trim = Left ( docpath ; adj1 - 1 ) ]; Case ( c1 = 1 ; trim & "/Downloads/" ; c1 = 0 ; trim & "/Downloads" ; "0" ) ) What’s nice about using this custom function is it will point to the Downloads folder on both Mac OS X and Windows, and you can refer to it just as easily as the TemporaryPath or DesktopPath. Instead of setting the $filePath variable to Get (TemporaryPath), you can set it as “DownloadsFolder” or whatever you name the custom function. Using these techniques, you should be able to spend a bit more extra time on your printing and exporting scripts, but gain all the benefits of files saving to the destination you want, with the file names you want. Afficher la totalité du billet
  8. Learn how to generate massive amounts of test data in your FileMaker app by leveraging new FileMaker 19 features that allow you to interact directly with JavaScript. Part of good app development is testing with conditions that are similar to the environment you can expect your app to eventually operate in. One of those conditions is the amount of data your app is working with. It’s a not infrequent occurrence that someone comes to us with a system that worked well with a few records but has grown slow and cumbersome as more data is entered. That’s why we develop with test data in the system so that we can easily spot situations where a technique used is not performant enough for production. This is great when we have an existing set of data to use but there are plenty of times where we’re tasked with an entirely new system concept that might not have years and years of data to work with. At that point, we need to generate on our own data. With the release of FileMaker 19, this task becomes much easier. Generating the Test Data This problem is not a new or unique development problem and we luckily have access to robust libraries whose sole purpose is to generate fake data for testing purposes. The library we’ll be working with today is called faker.js. This library exposes a wealth of different methods for generating various types of fake data. It ranges from contact names, company names, dates, currency amounts, internet domains, lorem ipsum text, phone numbers, file names and more. Setting Our File Up To kick this off, I’m going to setup a new table in my FileMaker app named Faker. This will be a single record table with a sole purpose of storing the code we use to generate fake data. The JavaScript Next, we need to write a little bit of JavaScript to actually generate our fake data. In this example, our goal is generate a number of contacts with each contact having a number of donations associated with them. We’ll end up with something that looks like this – A couple of notes here – FileMaker’s interaction with JavaScript happens through the web viewer which is a web portal that we can inject our own html into. With that in mind, we’re wrapping all of our JS code in <script> tags so that the web viewer can properly interpret and render it. The first script tag is loading the faker.js library from a CDN. You may consider downloading a minified version of the library and encapsulating in a script tag to improve performance and reduce reliance on outside resources. The fake data we’re generating here is very specific to this system and that will basically always be the case. Check out the faker.js docs for more fake data options. Back to FileMaker Now that we’ve got our JS code all set, we’re going to take it and place it in the HTML field of the single record Faker table. We’re also going to navigate to the Faker layout and create a web viewer. FileMaker’s functionality to perform JS code requires the JS to be loaded into a web viewer object. Our setup will look something like this: A few important points for all of this to work: Note the prefix “data:text/html,”. This is a required prefix for FileMaker to render and interpret our HTML/JS. It’s also important to note that we’ve named this web viewer object: In the web viewer settings (accessible by double clicking in layout mode), we need to enable our JavaScript to call FileMaker scripts:In browse mode, we’ll have something like this: The Scripts We’ll need a few scripts to actually run the library to generate the fake data as well as process it. The first one will navigate us to the Faker layout where the web viewer resides and run the fakeContacts JavaScript function. In order to run that JS function, we’ll be using the new in FileMaker 19 script step, “Perform JavaScript in Web Viewer”. This script step takes a web viewer object name, a JavaScript function name and any parameters you want to pass along. In our case, the call looks like this: When this JS function is called, it will generate a number of fake contacts (based on the variable, $numberOfContacts, we send as a parameter), package them into an array, and then call a FileMaker script to actually process the data. We do that by leveraging the new to FileMaker 19 function FileMaker.PerformScript. This is a JavaScript function that is injected and, therefore, available to us when in the context of the FileMaker web viewer object. That looks something like this (from our JS code): When this line is executed, the JavaScript code will call the FileMaker script “Generate Fake Contacts” and pass along our response variable as a parameter. From there, our Generate Fake Contacts script can process that response and create FileMaker records with that fake data. And that’s it! We’ve included a demo file so that you can see this in action. Login with admin and no password and dig in! Let us know if you have any questions in the comments below 😃 Afficher la totalité du billet
  9. Learn how to generate massive amounts of test data in your FileMaker app by leveraging new FileMaker 19 features that allow you to interact directly with JavaScript. Part of good app development is testing with conditions that are similar to the environment you can expect your app to eventually operate in. One of those conditions is the amount of data your app is working with. It’s a not infrequent occurrence that someone comes to us with a system that worked well with a few records but has grown slow and cumbersome as more data is entered. That’s why we develop with test data in the system so that we can easily spot situations where a technique used is not performant enough for production. This is great when we have an existing set of data to use but there are plenty of times where we’re tasked with an entirely new system concept that might not have years and years of data to work with. At that point, we need to generate on our own data. With the release of FileMaker 19, this task becomes much easier. Generating the Test Data This problem is not a new or unique development problem and we luckily have access to robust libraries whose sole purpose is to generate fake data for testing purposes. The library we’ll be working with today is called faker.js. This library exposes a wealth of different methods for generating various types of fake data. It ranges from contact names, company names, dates, currency amounts, internet domains, lorem ipsum text, phone numbers, file names and more. Setting Our File Up To kick this off, I’m going to setup a new table in my FileMaker app named Faker. This will be a single record table with a sole purpose of storing the code we use to generate fake data. The JavaScript Next, we need to write a little bit of JavaScript to actually generate our fake data. In this example, our goal is generate a number of contacts with each contact having a number of donations associated with them. We’ll end up with something that looks like this – A couple of notes here – FileMaker’s interaction with JavaScript happens through the web viewer which is a web portal that we can inject our own html into. With that in mind, we’re wrapping all of our JS code in <script> tags so that the web viewer can properly interpret and render it. The first script tag is loading the faker.js library from a CDN. You may consider downloading a minified version of the library and encapsulating in a script tag to improve performance and reduce reliance on outside resources. The fake data we’re generating here is very specific to this system and that will basically always be the case. Check out the faker.js docs for more fake data options. Back to FileMaker Now that we’ve got our JS code all set, we’re going to take it and place it in the HTML field of the single record Faker table. We’re also going to navigate to the Faker layout and create a web viewer. FileMaker’s functionality to perform JS code requires the JS to be loaded into a web viewer object. Our setup will look something like this: A few important points for all of this to work: Note the prefix “data:text/html,”. This is a required prefix for FileMaker to render and interpret our HTML/JS. It’s also important to note that we’ve named this web viewer object: In the web viewer settings (accessible by double clicking in layout mode), we need to enable our JavaScript to call FileMaker scripts: In browse mode, we’ll have something like this: The Scripts We’ll need a few scripts to actually run the library to generate the fake data as well as process it. The first one will navigate us to the Faker layout where the web viewer resides and run the fakeContacts JavaScript function. In order to run that JS function, we’ll be using the new in FileMaker 19 script step, “Perform JavaScript in Web Viewer”. This script step takes a web viewer object name, a JavaScript function name and any parameters you want to pass along. In our case, the call looks like this: When this JS function is called, it will generate a number of fake contacts (based on the variable, $numberOfContacts, we send as a parameter), package them into an array, and then call a FileMaker script to actually process the data. We do that by leveraging the new to FileMaker 19 function FileMaker.PerformScript. This is a JavaScript function that is injected and, therefore, available to us when in the context of the FileMaker web viewer object. That looks something like this (from our JS code): When this line is executed, the JavaScript code will call the FileMaker script “Generate Fake Contacts” and pass along our response variable as a parameter. From there, our Generate Fake Contacts script can process that response and create FileMaker records with that fake data. And that’s it! We’ve included a demo file so that you can see this in action. Login with admin and no password and dig in! Let us know if you have any questions in the comments below 😃 Afficher la totalité du billet
  10. Overview of the new Add-ons feature in FileMaker 19 With FileMaker 19 comes several new tools that bolster the toolkit we have access to as developers. Among them is the Add-ons feature which allows you to simply select pre-developed features to quickly add and remove from an existing app. This affords us an order of magnitude leap in our ability to iterate when working on our apps. If we consider what the process looked like before we can recognize the substantial benefits in terms of the amount of time saved for implementing features. So before Add-ons, to integrate some new functionality the process looked something like this depending on your feature’s dependencies: Import Tables Import Custom Functions Configure the ERD Update field definitions Add Layouts Import Scripts Copy over Value Lists Import Themes Copy over layout objects. Add Script Triggers Add Accounts/Privilege Sets Add Custom Menus Quite the process just to add something you’ve already spent the time developing. So, let’s look at the new addon feature process for some comparison. Go into layout mode and select the Add-ons pane Click the plus button Select the Add-on you want to add Click Choose From here FileMaker will now add all of the supporting infrastructure including layouts, layout objects, relationships, scripts etc. This is a big deal! It affords us the ability to quickly add functionality in a fraction of the time it previously did. Not only that we can just as easily remove the feature should we decide it doesn’t meet our particular need. That process looks like: In layout mode, select the add-on you’d like to remove Right-click it and select Uninstall Add-on From the dialogue select Uninstall Add-on That’s the whole process. Any schema, custom functions, layouts, scripts are removed as if they were never even there! This is an incredible step forward for FileMaker development and I am personally grateful the team over at Claris recognized the need that we have to make our code more portable. What is it that you’re are looking forward to with Add-ons and how it can impact your development? Please comment below. Afficher la totalité du billet
  11. Breaking down FileMaker’s new (and really easy) way to implement machine learning. With the release of FileMaker 19, an extremely easy way to implement very complex machine learning has been made available to MacOS and iOS FileMaker custom apps. Machine Learning offers the ability to automate “identification and analysis” processes by using trained machine learning “models”. With FileMaker, it’s now easy to script an entire decision tree with both machine learning and human interaction; Leading to very powerful workflows that can ensure a high quality of data. These models can be implemented to replace tasks that usually require human interaction to complete. One example of this is Sentiment Analysis, which can be used to gauge the tone of an email and automatically escalate it if the tone is determined to be angry. Another use case would be the identification of an uploaded picture, to determine if the content is likely to match the requested picture content. There are many use cases that can lead to significant savings in time for human interaction. Since FileMaker’s CoreML functionality takes advantage of recent iOS 11+ and MacOS 10.13+ updates that introduced the CoreML framework, FileMaker’s CoreML functionality is limited to iOS and MacOS as well. This should especially be taken into consideration for Windows and Linux FileMaker servers, as server-side scripts (Schedules and “Perform Script on Server”) will not be able to load CoreML functions). So just how easy is it to implement these machine learning models with FileMaker? It’s just three easy steps: Step 1: The Configure Machine Learning Model script step. You will utilize this script step to “install” a machine learning model, stored in a container field, into a named session object that can be used in Step 2. The script step has a number of parameters: Operation determines what action you are using to setup your model. The Vision option specifies that you will load a model that is designed to interact with images. The General option is used for non-image-based machine learning models, such as sentiment analysis of price estimation. The Unload option is used to unload the model from session memory when you are finished using it. This is important to do, as it frees up the resources that were being used by your custom app (like memory) to process the model. CoreML can potentially be resource-intensive, so be sure to unload the model when you are done with it. Name is the name of the model you are loading. This will be used in Step 2 to reference the loaded model by name. I recommend using a simple text name without special characters, spaces or numbers. For example: “checkImage” or “estimatePrice”. From indicates the container field that you are loading the trained machine learning model from. You can load container contents manually, or scripting it by using the Insert From URL script step. Step 2: The ComputeModel() function. This new function is used to take a loaded machine learning model (by name) and passing it specific contents for machine learning processing. The first parameter to this function is modelName, which is provided from Step 1 above. Other parameters to this function are flexible by using [Key;Value] pair parameters (same as with other functions like Substitute() that support flexible parameters). So a ComputeModel() function that passes three parameters for estimating the cost of a house may look like this: ComputeModel( “estimatePrice” ; [ “zipCode” ; “43215” ] ; [ “bedrooms” ; 3 ] ; [ “bathrooms” ; 2 ] ) Or a function that passes an image for analysis may look something like this: ComputeModel( “isThisAToaster” ; “image” ; MyTable::ImageField ) An additional note for Vision type CoreML models is that they also support two additional features that can limit the number of results returned. This is important as some machine learning models for image analysis can return thousands of results (for instance, if you had a vision model that returned the coordinates of all the green pixels in an image). These two additional parameters are: confidenceLowerLimit: A numeric value between 0 and 1.0. Confidence is a percent measurement of how sure the machine learning model is of the request. For example, you might get a confidence value of .98 when you pass a picture of a toaster to the above calculation. If you made this parameter 1.0, you may not get any results back, as most machine learning models will not return a 100% accurate match depending on the training methodology. This is extremely useful for filtering out low level matches though, saving you processing time later. returnAtLeastOne: This is a boolean (1 or zero). This parameter is only useful in conjunction with the above parameter. Just in case you set a high confidence filter and no results match, then the result with the highest confidence will be returned if this parameter is enabled. Step 3: Evaluate the model results. For the majority of use cases, the above ComputeModel() function will be used in a Set Variable or Set Field script step so that the results of the machine learning analysis can be checked. Results from most machine learning models are returned as JSON, so it’s quite easy with FileMaker’s native JSON functions to process the model results. For example, if I passed this calculation with my vision model to identify toasters in an image: ComputeModel( “locateToasters” ; [“image” ; MyTable::ImageField] ; [“confidenceLowerLimit” ; 1] ; [“returnAtLeastOne” ; 1] ) I would get the result with the highest confidence similar to this: [{“location”:”upper-left”,”confidence”:0.920526770564}] And I would be able to create a simple script that marks the toaster location in my record: Set Variable [ $result ; JSONGetElement( ComputeModel ( etc…) ; 0 ) ] If [ JSONGetElement( $result ; “confidence” ) > .75 ] Set Field [ MyTable::ToasterDetails ; “There is a toaster located in the “ & JSONGetElement( $result ; “location” ) & “ of the picture.” ] End If That’s it! Easy machine learning integration with just a few steps in FileMaker 19! Do you have ideas for how you would use machine learning? Please comment below. Afficher la totalité du billet
  12. Breaking down FileMaker’s new (and really easy) way to implement machine learning. With the release of FileMaker 19, an extremely easy way to implement very complex machine learning has been made available to MacOS and iOS FileMaker custom apps. Machine Learning offers the ability to automate “identification and analysis” processes by using trained machine learning “models”. With FileMaker, it’s now easy to script an entire decision tree with both machine learning and human interaction; Leading to very powerful workflows that can ensure a high quality of data. These models can be implemented to replace tasks that usually require human interaction to complete. One example of this is Sentiment Analysis, which can be used to gauge the tone of an email and automatically escalate it if the tone is determined to be angry. Another use case would be the identification of an uploaded picture, to determine if the content is likely to match the requested picture content. There are many use cases that can lead to significant savings in time for human interaction. Since FileMaker’s CoreML functionality takes advantage of recent iOS 11+ and MacOS 10.13+ updates that introduced the CoreML framework, FileMaker’s CoreML functionality is limited to iOS and MacOS as well. This should especially be taken into consideration for Windows and Linux FileMaker servers, as server-side scripts (Schedules and “Perform Script on Server”) will not be able to load CoreML functions). So just how easy is it to implement these machine learning models with FileMaker? It’s just three easy steps: Step 1: The Configure Machine Learning Model script step. You will utilize this script step to “install” a machine learning model, stored in a container field, into a named session object that can be used in Step 2. The script step has a number of parameters: Operation determines what action you are using to setup your model. The Vision option specifies that you will load a model that is designed to interact with images. The General option is used for non-image-based machine learning models, such as sentiment analysis of price estimation. The Unload option is used to unload the model from session memory when you are finished using it. This is important to do, as it frees up the resources that were being used by your custom app (like memory) to process the model. CoreML can potentially be resource-intensive, so be sure to unload the model when you are done with it. Name is the name of the model you are loading. This will be used in Step 2 to reference the loaded model by name. I recommend using a simple text name without special characters, spaces or numbers. For example: “checkImage” or “estimatePrice”. From indicates the container field that you are loading the trained machine learning model from. You can load container contents manually, or scripting it by using the Insert From URL script step. Step 2: The ComputeModel() function. This new function is used to take a loaded machine learning model (by name) and passing it specific contents for machine learning processing. The first parameter to this function is modelName, which is provided from Step 1 above. Other parameters to this function are flexible by using [Key;Value] pair parameters (same as with other functions like Substitute() that support flexible parameters). So a ComputeModel() function that passes three parameters for estimating the cost of a house may look like this: ComputeModel( “estimatePrice” ; [ “zipCode” ; “43215” ] ; [ “bedrooms” ; 3 ] ; [ “bathrooms” ; 2 ] ) Or a function that passes an image for analysis may look something like this: ComputeModel( “isThisAToaster” ; “image” ; MyTable::ImageField ) An additional note for Vision type CoreML models is that they also support two additional features that can limit the number of results returned. This is important as some machine learning models for image analysis can return thousands of results (for instance, if you had a vision model that returned the coordinates of all the green pixels in an image). These two additional parameters are: confidenceLowerLimit: A numeric value between 0 and 1.0. Confidence is a percent measurement of how sure the machine learning model is of the request. For example, you might get a confidence value of .98 when you pass a picture of a toaster to the above calculation. If you made this parameter 1.0, you may not get any results back, as most machine learning models will not return a 100% accurate match depending on the training methodology. This is extremely useful for filtering out low level matches though, saving you processing time later. returnAtLeastOne: This is a boolean (1 or zero). This parameter is only useful in conjunction with the above parameter. Just in case you set a high confidence filter and no results match, then the result with the highest confidence will be returned if this parameter is enabled. Step 3: Evaluate the model results. For the majority of use cases, the above ComputeModel() function will be used in a Set Variable or Set Field script step so that the results of the machine learning analysis can be checked. Results from most machine learning models are returned as JSON, so it’s quite easy with FileMaker’s native JSON functions to process the model results. For example, if I passed this calculation with my vision model to identify toasters in an image: ComputeModel( “locateToasters” ; [“image” ; MyTable::ImageField] ; [“confidenceLowerLimit” ; 1] ; [“returnAtLeastOne” ; 1] ) I would get the result with the highest confidence similar to this: [{“location”:”upper-left”,”confidence”:0.920526770564}] And I would be able to create a simple script that marks the toaster location in my record: Set Variable [ $result ; JSONGetElement( ComputeModel ( etc…) ; 0 ) ] If [ JSONGetElement( $result ; “confidence” ) > .75 ] Set Field [ MyTable::ToasterDetails ; “There is a toaster located in the “ & JSONGetElement( $result ; “location” ) & “ of the picture.” ] End If That’s it! Easy machine learning integration with just a few steps in FileMaker 19! Do you have ideas for how you would use machine learning? Please comment below. Afficher la totalité du billet
  13. Overview of the new Add-ons feature in FileMaker 19 With FileMaker 19 comes several new tools that bolster the toolkit we have access to as developers. Among them is the Add-ons feature which allows you to simply select pre-developed features to quickly add and remove from an existing app. This affords us an order of magnitude leap in our ability to iterate when working on our apps. If we consider what the process looked like before we can recognize the substantial benefits in terms of the amount of time saved for implementing features. So before Add-ons, to integrate some new functionality the process looked something like this depending on your feature’s dependencies: Import Tables Import Custom Functions Configure the ERD Update field definitions Add Layouts Import Scripts Copy over Value Lists Import Themes Copy over layout objects. Add Script Triggers Add Accounts/Privilege Sets Add Custom Menus Quite the process just to add something you’ve already spent the time developing. So, let’s look at the new addon feature process for some comparison. Go into layout mode and select the Add-ons pane Click the plus button Select the Add-on you want to add Click Choose From here FileMaker will now add all of the supporting infrastructure including layouts, layout objects, relationships, scripts etc. This is a big deal! It affords us the ability to quickly add functionality in a fraction of the time it previously did. Not only that we can just as easily remove the feature should we decide it doesn’t meet our particular need. That process looks like: In layout mode, select the add-on you’d like to remove Right-click it and select Uninstall Add-on From the dialogue select Uninstall Add-on That’s the whole process. Any schema, custom functions, layouts, scripts are removed as if they were never even there! This is an incredible step forward for FileMaker development and I am personally grateful the team over at Claris recognized the need that we have to make our code more portable. What is it that you’re are looking forward to with Add-ons and how it can impact your development? Please comment below. Afficher la totalité du billet
  14. As FileMaker developers, it’s common practice to need to contact the client records stored in the database, often scheduled daily, or weekly, or by a specific event. Without FileMaker’s ability to automate emails, this could become very time consuming. This blog post will cover the essential scripting techniques required to save time by automating emails and optimize communication with clients by attaching files. The Send Mail script step Right off the bat, the most important thing to understand is the Send Mail script step. Make sure to read all of the documentation for the FileMaker 18 version of this script step. There were no big changes to this script step, with the recent release of 18, but an important change to this script step was introduced with FileMaker 17, and that is the ability to attach multiple attachments to an email. There is a great deal of options that come along with this script step. The first option is specified on the same line as the script step, the option to leave dialog on or off. Leaving dialog on will bring up the default email application, and leave it open for review, rather than sending it. In some email applications, the new message is left in the Drafts folder. If With Dialog is left off, the email is composed and placed in the email applications Outbox, ready to be sent. Opening the options dialog, presents you with much more choices that you will need to understand to be able to use this script step properly. The first option being Send Via:, with the options of Email Client, or SMTP Server. SMTP server The Simple Mail Transfer Protocol, also known as SMTP, is a communication protocol for email transmission. SMTP is used for sending, not receiving mail. At this point, you may still be wondering why you would choose SMTP. SMTP is one less layer of complexity that your application must deal with. Using the mail client introduces additional points of failure over sending via SMTP directly. You can avoid issues you would otherwise need to consider, such as, is FileMaker compatible with the mail client? and is the mail client configured correctly? To send emails through SMTP with FileMaker, you must provide sender information, as well as SMTP Server information. When you choose SMTP Server in the Send Mail Options dialog, a new dialog box opens for the SMTP options. Explanations of each field within this dialog can be found in the chart below. Send Mail script step options Once you’ve decided if you will be sending mail through the E-Mail Client or an SMTP Server, the next option to consider is if you want to send one email using data from the current record or, send multiple emails (one for each client in the found set). Sometimes, all emails generated need to be sent to one static email address, but things are not always that simple. You will often need to specify the destination emailfield with a field name, or a calculation. Keep in mind that when utilizing scripting, you can send emails to multiple recipients, while the send email using data from the current record is selected. For the To, CC, BCC and Subject fields, you will have the options to Specify by Field, Or Specify by Calculation. For situations where each record has one field per record, storing one email address each, all you need to do is specify that field. In situations where you need to send the email to multiple emails stored on one record, you need to make sure that the emails are separated properly, using carriage returns (¶). This can still be done either through a field, or a calculation, just make sure, if using specify by field that the field is formatted correctly. You may want to use a calculation field that cannot be edited by users, to concatenate the list of emails. The body Unlike the previously covered email fields, the Body presents a third option, to Insert Text from a File. Selecting this option will open a dialog that asks you to choose a file. Note that to be able to select a file, it must be a .txt file. A useful technique for creating a longer and/or more dynamic Body is using a Let statement to set a variable. You may also need to use a Let statement to specify a To, CC, or BCC, or Subject, but I use it almost every time I specify the calculation for a Body. Below is an example of a calculation I would use for a $body variable in a script to send an email to a client. Using a Let statement like this will make the calculation easier to read and make changes to, if you need to come back to it. Also, this will help anyone else who needs to make changes to the calculation. When you don’t make your Body calculation dynamic like this, you will likely soon be overwhelmed by the amount of concatenations you need to read to make what could be a simple change. The following calculation displays the same output, but is much harder to read and change: No matter how many indents and carriage returns you add to this calculation, it will never be easy for a human to read. So, help your coworkers out by using Let statements and variables to construct your email options. Attachments The last option on the Send Mail [] options dialogue is to Attach Files. The button is found at the bottom left of the Send Mail dialog box and it opens up its own dialog box. If you need to just attach one file, the Add File… button at the top right will pull up the Finder or File Explorer. Selecting a file from this window will properly assemble the path needed. You still have the ability to construct these paths manually, but it is recommended to use variables for the construction. As mentioned earlier, FileMaker 17 introduced the ability to add multiple attachments to an email. This can be done in many ways, the first being to simply select multiple files using Command/Control or Shift. Doing this will format the multiple paths correctly, using carriage returns. This correct file path should be noted if you plan on attaching multiple files by constructing the paths yourself with a variable. The carriage returns will need to be included either within the variable, if you will be building or multiple paths within one variable (done using list function in the first image below), or in the specify file box, if you have a different variable for each path. (second image below) Conclusion Understanding the Send Mail script step is absolutely necessary in FileMaker development. Without FileMaker’s ability to automate emails, you could end up needing an employee whose entire job is writing emails to clients, or users of a file. It’s important to understand how to set up email automation in a modular fashion so that other developers can understand and modify the scripts, if need be. Hopefully this blog post helped you understand the essential scripting techniques required to save time by automating emails and optimize communication with clients by attaching files. Afficher la totalité du billet
  15. As FileMaker developers, it’s common practice to need to contact the client records stored in the database, often scheduled daily, or weekly, or by a specific event. Without FileMaker’s ability to automate emails, this could become very time consuming. This blog post will cover the essential scripting techniques required to save time by automating emails and optimize communication with clients by attaching files. The Send Mail script step Right off the bat, the most important thing to understand is the Send Mail script step. Make sure to read all of the documentation for the FileMaker 18 version of this script step. There were no big changes to this script step, with the recent release of 18, but an important change to this script step was introduced with FileMaker 17, and that is the ability to attach multiple attachments to an email. There is a great deal of options that come along with this script step. The first option is specified on the same line as the script step, the option to leave dialog on or off. Leaving dialog on will bring up the default email application, and leave it open for review, rather than sending it. In some email applications, the new message is left in the Drafts folder. If With Dialog is left off, the email is composed and placed in the email applications Outbox, ready to be sent. Opening the options dialog, presents you with much more choices that you will need to understand to be able to use this script step properly. The first option being Send Via:, with the options of Email Client, or SMTP Server. SMTP server The Simple Mail Transfer Protocol, also known as SMTP, is a communication protocol for email transmission. SMTP is used for sending, not receiving mail. At this point, you may still be wondering why you would choose SMTP. SMTP is one less layer of complexity that your application must deal with. Using the mail client introduces additional points of failure over sending via SMTP directly. You can avoid issues you would otherwise need to consider, such as, is FileMaker compatible with the mail client? and is the mail client configured correctly? To send emails through SMTP with FileMaker, you must provide sender information, as well as SMTP Server information. When you choose SMTP Server in the Send Mail Options dialog, a new dialog box opens for the SMTP options. Explanations of each field within this dialog can be found in the chart below. Send Mail script step options Once you’ve decided if you will be sending mail through the E-Mail Client or an SMTP Server, the next option to consider is if you want to send one email using data from the current record or, send multiple emails (one for each client in the found set). Sometimes, all emails generated need to be sent to one static email address, but things are not always that simple. You will often need to specify the destination emailfield with a field name, or a calculation. Keep in mind that when utilizing scripting, you can send emails to multiple recipients, while the send email using data from the current record is selected. For the To, CC, BCC and Subject fields, you will have the options to Specify by Field, Or Specify by Calculation. For situations where each record has one field per record, storing one email address each, all you need to do is specify that field. In situations where you need to send the email to multiple emails stored on one record, you need to make sure that the emails are separated properly, using carriage returns (¶). This can still be done either through a field, or a calculation, just make sure, if using specify by field that the field is formatted correctly. You may want to use a calculation field that cannot be edited by users, to concatenate the list of emails. The body Unlike the previously covered email fields, the Body presents a third option, to Insert Text from a File. Selecting this option will open a dialog that asks you to choose a file. Note that to be able to select a file, it must be a .txt file. A useful technique for creating a longer and/or more dynamic Body is using a Let statement to set a variable. You may also need to use a Let statement to specify a To, CC, or BCC, or Subject, but I use it almost every time I specify the calculation for a Body. Below is an example of a calculation I would use for a $body variable in a script to send an email to a client. Using a Let statement like this will make the calculation easier to read and make changes to, if you need to come back to it. Also, this will help anyone else who needs to make changes to the calculation. When you don’t make your Body calculation dynamic like this, you will likely soon be overwhelmed by the amount of concatenations you need to read to make what could be a simple change. The following calculation displays the same output, but is much harder to read and change: No matter how many indents and carriage returns you add to this calculation, it will never be easy for a human to read. So, help your coworkers out by using Let statements and variables to construct your email options. Attachments The last option on the Send Mail [] options dialogue is to Attach Files. The button is found at the bottom left of the Send Mail dialog box and it opens up its own dialog box. If you need to just attach one file, the Add File… button at the top right will pull up the Finder or File Explorer. Selecting a file from this window will properly assemble the path needed. You still have the ability to construct these paths manually, but it is recommended to use variables for the construction. As mentioned earlier, FileMaker 17 introduced the ability to add multiple attachments to an email. This can be done in many ways, the first being to simply select multiple files using Command/Control or Shift. Doing this will format the multiple paths correctly, using carriage returns. This correct file path should be noted if you plan on attaching multiple files by constructing the paths yourself with a variable. The carriage returns will need to be included either within the variable, if you will be building or multiple paths within one variable (done using list function in the first image below), or in the specify file box, if you have a different variable for each path. (second image below) Conclusion Understanding the Send Mail script step is absolutely necessary in FileMaker development. Without FileMaker’s ability to automate emails, you could end up needing an employee whose entire job is writing emails to clients, or users of a file. It’s important to understand how to set up email automation in a modular fashion so that other developers can understand and modify the scripts, if need be. Hopefully this blog post helped you understand the essential scripting techniques required to save time by automating emails and optimize communication with clients by attaching files. Afficher la totalité du billet
×
×
  • Create New...