FileMaker Solution: logging usage – Part 2

At uLearnIT, we love solving your problems. Here is Part 2 of the latest problem solved for a client using our mentoring services. If you missed Part 1, it is here.

Request

In an existing FileMaker solution, we would like to know if certain scripts and layouts are being used. Over the years, the solution has been added to and updated in a haphazard manner and we would like to clean it up. How can we find out which scripts and layouts are in use?

Solution

From Part 1, the key to this solution is to automatically log the use of scripts and layouts by triggering a script. The script will record the name of the layout or script used and then create a log record. The log record will be created in a special table for the purpose.

Script use

The script to log script use will be called at the start of each script – using the Perform Script script step. It will pass the currently running script name as a script parameter that will be entered into a log record. To set up the script step in any script:

  1. Open the Script Workspace and open a script.
  2. Add the script step Perform Script to the start of the script.
  3. Specify the Log script use script.
  4. Set the Optional script parameter to Get ( ScriptName )
Perform Script with script selected and script parameter defined

The script used to Log Script Use is as follows:

New Window [ Style: Card; Using layout: “uselog” (uselog); Height: 100; Width: 100; Top: 0; Left: -1000; Dim parent window: No ]
New Record/Request
Set Field 
[ uselog::name; Get ( ScriptParameter ) ]
Set Field [ uselog::item; "script" ]
Close Window [ Current Window ]

In the script above, the operation is performed in a card window off the user screen. This ensures that it does not interfere with the user’s normal actions or that of any running script. Since the parent screen does not dim, the user should not notice the script run. 

The script creates a new card window and goes to a layout to create a new log record. It uses Set Field script steps to set the name field with the script parameter (in this case the script name), and the item field with the text string script.

Add the Perform Script step (simply copy and paste between scripts) to every script for which you want to log use. Over time as the solution is used, the log records build an account of script use. This can then be analysed to see which script are most commonly used and which scripts are rarely or not used.

Addendum

A suggestion tweeted by @tonywhitelive was to also record Script Parameter, File Name and Layout Name when logging scripts. 

The file name would be useful when logging scripts running outside of the file where the log record exists. The script parameter and the layout name will provide some useful data about how and where the script was triggered.

So we will need to add three more fields to the log record – parameter, file, layout. And then adjust the script logging script to unpack and apply the various values.

When calling the new script, the parameter will use the List function to capture multiple pieces of data as a list of values:

List ( Get(ScriptName); Get(FileName); Get(LayoutName); Get(ScriptParameter) )

These values can then easily be unpacked when received using the GetValue function.

Parameter values unloaded into variables and then used to populate log fields

So there you have it – even more functional script use logging. Thanks Tony!

Do you need uLearnIT to solve a problem?

We can do the same for you. Just let us know what you are struggling with and we will provide a cost effective solution. We have saved our customers hours of Googling answers and frustration trying things that never worked for them.

We can do the same for you.

Contact us now before you waste any more time!

FileMaker Solution: logging usage – Part 1

At uLearnIT, we love solving your problems. Here is the latest one solved for a client using our mentoring services.

Request

In an existing FileMaker solution, we would like to know if certain scripts and layouts are being used. Over the years, the solution has been added to and updated in a haphazard manner and we would like to clean it up. How can we find out which scripts and layouts are in use?

Solution

It is unreliable and unwieldy for users to manually log their usage. Often, they do not know which scripts and which layouts they use. If they report the use of buttons, then they also have to report which screen and then the developer has to decipher the use.

The key to this solution is to automatically log the use of scripts and layouts. This can be done by triggering a script. The script will need to record the name of the layout or script used and then create a log record. The log record will be created in a special table for the purpose. The log record will have fields for:

  • item (type) – layout or script
  • name – of the layout or script
  • account – name of the account currently in use
  • creation – timestamp when created

The item will be set by the script; name will come from the script parameter; account and creation will be auto-entered.

Layout use

The script to log layout use will be triggered OnLayoutEnter – after a layout is loaded. It will pass the layout name as a script parameter that will be entered into a log record. To set this trigger for any layout:

  1. Navigate to the layout and enter Layout mode.
  2. Select Layouts > Layout Setup… and then Script Triggers.
  3. Select the OnLayoutEnter event and select the required script.
  4. Set the Optional script parameter to Get ( LayoutName )
Layout Setup – Script Trigger configuration

The script used to Log Layout Use is as follows:

New Window [ Style: Card; Using layout: “uselog” (uselog); Height: 100; Width: 100; Top: 0; Left: -1000; Dim parent window: No ]
New Record/Request
Set Field 
[ uselog::name; Get ( ScriptParameter ) ]
Set Field [ uselog::item; "layout" ]
Close Window [ Current Window ]

In the script above, the operation is performed in a card window off the user screen. This ensures that it does not interfere with the user’s normal actions or that of any running script. Since the parent screen does not dim, the user should not notice the script run. 

The script creates a new card window and goes to a layout to create a new log record. It uses Set Field script steps to set the name field with the script parameter (in this case the layout name), and the item field with the text string layout.

Repeat the layout script trigger for every layout for which you want to log use. Over time as the solution is used, the log records build an account of layout use. This can then be analysed to see which layouts are most commonly used and which layouts are rarely or not used. 

Use log for layout items

See Part 2 for scripts…

In Part 2 of this post, we will look at how to log the use of scripts in a solution. It is a simple extension of the above method for layouts.

Do you need uLearnIT to solve a problem?

We can do the same for you. Just let us know what you are struggling with and we will provide a cost effective solution. We have saved our customers hours of Googling answers and frustration trying things that never worked for them.

We can do the same for you.

Contact us now before you waste any more time!

FileMaker Solution: entering partial dates

At uLearnIT, we love solving your problems. Here is the latest one solved for a client using our mentoring services.

Request

In our Equipment table there is a field for DOM (date of manufacture). It is defined as a text field since the data is just a month and a year such as 03/10 or 11/15. We would prefer the service techs to enter the data as written. We don’t want them rejecting the process because it’s uncomfortable.

But then we need to perform simple calculations on the DOM. For example,  if the DOM is more than 5 years past, a “Level 4” service is due.

Solution

Part 1: Data Entry

It would be great to allow users to enter a month and year as the DOM in a number of ways. So let’s allow them to enter say March 2015 as any of 315, 0315, 3/15 or 03/15. And then reset the data on field exit to the standard 03/15. 

This is done with a field option which is an auto-entered calculation. Importantly, the option Do not replace existing value of field (if any) was unchecked – so that the calculation is evaluated when leaving the field.

Case ( 
Length ( Self ) = 3;
"0" & Left (Self; 1) & "/" & Right (Self; 2);
PatternCount (Self ; "/") and Length (Self) = 5;
Self;
PatternCount (Self ; "/") and Length (Self) = 4;
"0" & Self;
Length ( Self ) = 4;
Left (Self; 2) & "/" & Right (Self; 2);
"Error"
)

In this Case statement, there are four tests:

  1. if the length of the data is 3 characters, then add a leading zero and insert a slash character – so 315 becomes 03/15
  2. if there is a slash and the length is five characters, then leave as is – so 03/15 would be left as is (returns Self)
  3. if there is a slash and the length is four characters, then add a leading zero – so 3/15 becomes 03/15
  4. if the length is four characters, then insert a slash in the middle – so 0315 becomes 03/15

And if all those tests fail, it returns the result “Error”. That may happen if you enter 35 or 032015. 

Exceptions could be handled in other ways but it was not needed here.

Part 2: Calculate a proper date

Now that we have some standard data to work with, we can easily convert that into a proper date with a calculation. The decision was made to standardise on the first of the month.

So we set up a calculation field (DOM as date) using the expression:

Let ([
raw = DOM; // the field entered as MM/YY
themonth = GetAsNumber (Left (raw ; 2));
theyear = GetAsNumber (Right (raw ; 2));
theyear = theyear + 2000 - If(theyear >50; 100);
// convert to four digit
thedate = Date (themonth ; 1 ; theyear)
// date of first of month ]; thedate )

The process in the Let statement is:

  1. The field (DOM) is set into a variable called raw.
  2. Then raw is processed to get the month and the year – first and last two characters respectively. 
  3. Then the month and year are used to get the date of the first day of the month.
  4. The year is converted into four digits.
  5. The Let function returns the proper date (calculation result type is date)

QED

So that is the simple solution that lets techs enter the date quickly and easily, and then use it to move forward into other calculations to work out service requirements and more.

Do you need uLearnIT to solve a problem?

We can do the same for you. Just let us know what you are struggling with and we will provide a cost effective solution. We have saved our customers hours of Googling answers and frustration trying things that never worked for them.

We can do the same for you.

Contact us now before you waste any more time!

Mentoring services – getting the help when you need it

You probably know that uLearnIT offers hands-on FileMaker classes. These are the ideal way to get quickly up to speed with everything you need to know about FileMaker at a specific level. The classes give you the chance to ask questions and get help on your individual projects. But there is a lot of content to cover in two days.

So what do you do when you leave the class and it is just you, sitting at your desk, trying to get something to work? Google it! Three hours and some funny cat videos later you are still not any closer to a solution.

You need a mentor. Someone who can jump in and look at what you want to achieve, what you have been doing and where you are stuck. This sort of on-demand help is ideal for those who know what they want to do but have just hit a small brick wall in achieving it.

uLearnIT offers FileMaker mentoring services to give you a literal “hand up” on your solution. Read more about how it works and how to get started at our FileMaker Mentoring page. It may be the best investment you can make in your own FileMaker development.