Covering every plug-in available, in addition to being obsolete by the time you read this, would probably make this book twice its current size. So instead, we’ll discuss some of the most useful plug-ins and see examples of how they work. (Be sure to check out the Web sites of the publishers of each plug-in for the most recent versions.)
First you’ll learn about the Auto Update plug-in that is included with every copy of FileMaker. (FileMaker includes other plug-ins, such as the Web Companion, Local Data Access Companion, and Remote Data Access Companion.
Once you’ve learned about the Auto Update plug-in, we’ll review a number of other third-party plug-ins that you may find useful. For each showcased plugin, you’ll also get information about where you can purchase it and how much a single-user license costs (at press time anyway). This usually isn’t the only kind of license available for plug-ins. There are generally discounts for multiple copies and different pricing for developers. After a brief introduction to each plug-in there are some real-world examples of how the plug-in might be implemented in a database system.
FileMaker 5.5 introduced a new feature with the release of the Server version. One of the challenges with working with plug-ins is keeping them up to date. If you’re using a plug-in on a network of dozens (or hundreds) of users, and a new version of the plug-in is released, you used to have to physically go to each computer system and install the plug-in. The Auto Update plug-in renders this obsolete, allowing you to place the plug-in on the same machine serving the databases and have users receive the new version of the plug-in automatically the next time they log on to the system.
The plug-in works by keeping versions of the plug-ins you might want to update on the server in a folder called AutoUpdate. In addition to the plug-ins, this folder also holds text files that store the version numbers of the plug-ins.
The procedure for updating a plug-in is to check the version of the plug-in installed on the client computer (by using the plug-in’s own external Version function) against the text file that stores the version number of the plug-in on the server by using the FMSAUC-FindPlugin function at the start up of your FileMaker system. (This must be done on a platform-specific basis.)
You’ll use the Status(CurrentPlatform) function, you check which platform you are running on, and depending on the results of this function, you check for the specific plug-in version for that platform. If the version of the plug-in on the server is later than the version on the local machine, you use the FMSAUC-UpdatePlugin function to download the newer version of the plug-in to the local machine, replacing the old version and enabling the new version. The AutoUpdate function takes care of installing the plug-in to the correct location and enabling it so that FileMaker doesn’t have to be relaunched.
For the Auto Update plug-in to work correctly, FileMaker Server has to be configured to allow client machines to update plug-ins. This is done slightly differently depending on the platform that FileMaker Server is running on. For Macintosh systems running Mac OS 8 or 9, select Preferences from the Edit menu. Click the Files tab and check the preference for “Allow FileMaker Pro guests to download updates automatically” (Figure below).
If the FileMaker Server is running on Mac OS X, launch FileMaker Server Config and select Preferences from the FMServer Config menu to find the Files tab and check the box as in Mac OS 8/9.
Setting the Auto Update preference on Mac OS 8/9.
On Windows, open the FileMaker Server Console. Select FileMaker Server in the console tree and choose Properties from the Action menu. Click the Files tab and check the box for the Auto Update preference.
Lastly, if you’re running the server on Linux, open the “fmserver.conf” file in a text editor while logged in as the root user. Find the line that begins “UseAutoUpdate” and make sure that it reads “UseAutoUpdate ON”. Save your changes and reload the configuration file.
On the CD is a sample database that demonstrates the Auto Update plug-in. To try this database out, it needs to be served with FileMaker Server and opened on a client machine. The sample database updates the Server Administration plug-in, which allows FileMaker to remotely administer FileMaker server. You won’t learn about the details of the Server Administration plug-in because FileMaker doesn’t provide any details for it. It is used by FileMaker Pro only, not for solutions that developers create.
Take a Test-Drive
Create a new database in FileMaker and give it two fields: gExternal, which is a global text field, and Version, which is a calculation field with a text result. The calculation should be External( "FMA-Version", 0 ).
Here’s the script that performs the update:
This script first sets gExternal to an empty string. You do this so that you can check at the end of the script if it is still empty or not. If it isn’t, then an updatebmust have been attempted.
Next you check the platform. The Status( CurrentPlatform ) function returns a “2” for Windows 9x and a “-2” for any version of Windows NT, so getting the absolute value of the result of this function lets you know you’re working with a Windows machine. You then check to see if the version of the Windows plug-in on the server is later than the version on the local machine, and if it is, you downloadvthe newer version using the UpdatePlugin function.
If the computer isn’t running Windows you check for it running on a Macintosh and download the appropriate plug-in (if the version is later) based on whether you’re running Mac OS Classic or Mac OS X.
Lastly, you check to see if gExternal is empty or not. If gExternal is not empty, the script must have attempted an update. Your script step that updates the plug-in is a Set Field step that uses gExternal as a repository. If everything works fine, this field will get set to 0. If there is a problem, an error number will be placed into this field. So you check not only if the field is not empty but also that the right word of the field is not 0. If this is the case, then an error must have occurred, and you report this to the user.
To run this you must serve the database on a machine running FileMaker Server 5.5 or later, set the server to allow auto updates, and ensure that the Server Administration plug-in is in the appropriate folder for the platform being used as a server. Then open the database on a client machine and run the script.
When the script is finished, assuming everything worked correctly, you should have the updated Server Administration plug-in in your plug-ins folder on the client machine.
The Troi File plug-in offers the ability to read and write files to the hard drive and manipulate the files as you would from the Finder or Windows Explorer. It also gives you the ability to search your hard drive, although unfortunately you can search only within a specified folder. The plug-in offers dozens of functions to handle files and folders. Many of the functions reference an entity called the DefaultFileSpec, which is the file that the plug-in’s functions work from by default. Before using these functions this default file needs to be set. This works out well because you don’t have to pass the file as a parameter for each function that needs to work with that file.
The capabilities of this plug-in aren’t limited to text files, although most of the functions provided are intended to work with text files. However, most of the file functions could be done within FileMaker, although not as easily. For instance, many of the functions operate by getting the data in a file and placing that data into a field. This could be done with FileMaker alone by importing the data using the Import Records script step, although it won’t be as easy to do with FileMaker alone. Similarly, some of the functions operate by saving data to a file from the fields in a database, and again, this could be done with FileMaker by using the Export Records script step, but, again, not as easily as with the Troi File plug-in.
There is at least one area where the Troi File plug-in allows something not possible with FileMaker alone, and that is importing images whose name you don’t know in advance. Using the Insert Picture script step, you can either insert a picture with a known name or you can prompt the user to select the file. But what if you have a folder of images and you would like to create a record in FileMaker for each image and import the image? If you’re on a Mac and are satisfied with importing the actual image rather than a reference to the image file, you can do this sort of thing with AppleScript, but making the solution work on Windows or allowing the ability to import a reference to the image (instead of the image itself) is possible with the Troi File plug-in. You’re going to build a script that does just that: It will prompt the user to select a folder of images and will import the images themselves as separate records into FileMaker.
Even though the plug-in enables you to perform this task, you still have some work to do with it. Here’s the basic outline of how this is accomplished. First, you have the user select a folder. Then you create a list of all the files in that folder and place the list in a field that you can loop through. Then for each file in the list, you use one of the Troi File functions to copy a reference of the file and then you paste that reference into a new record’s container field. The following is the script that accomplishes all of this. You’ll find the script in the database Troi- File.fp5 on the CD-ROM. If you wish to create your own version of this, create an empty database using the fields that are listed in Table below.
Fields for Troi File Plug-in Example
Once you have created the database with these fields, make sure that the Image field is on the layout from which you run the script:
When you run this script in the sample database on the CD-ROM (after copying the database to your hard drive so that it can be altered), you will be presented with a dialog box asking you to select a folder of images. Since there is no error checking in this script, be sure to select a folder that contains only images. After you make your selection, each ofbthe images in the folder will be imported as a new record in the database.
One thing to note about this script is that you haven’t done any error checking with it. If you decide to use this or a similar script in your own solution, it’s a good idea to check for problems, such as when the files in the folder aren’tbgraphic files. But because this is a demonstration of how the plug-in works, you’ll only have to deal with the addition of error checking in an exercise. You also won’t check to make sure that the plug-in is actually installed, although you would certainly want to do this in your own solutions. Another possible error is that you are embedding one function within another, and the embedded function could return an error, which you won’t catch the way you’ve built this script.
Lastly, since your sample database has only a single layout, you don’t use a Go to Layout script step, although you would in a real solution, since the Paste script step only works if the field you are pasting into is on the current layout. This is the practice you will use as you experiment with using these plug-ins, although you’ll see some of the more common problems that can arise.
Another enhancement you might make to the script is to save the path to the file so that you can easily find it later, or, perhaps, use the Troi File plug-in’s TrFile-Launch function to open the file in a graphic editing program such as Photoshop.
Troi has built a powerful tool here for FileMaker developers, and this is just giving you a quick taste, as you’ll do with the other showcased plug-ins. There are many possible errors that could be returned by the plug-in’s functions, and you’ll want to make copious use of error checking in your actual solution. Be sure to read the manual for the plug-in and check out the sample databases that are included with it.
FileMaker includes many functions that can help with parsing text, but there’s always room for improvement. The Troi Text plug-in is one of those whose functionality could be entirely duplicated within FileMaker using scripts and layout tricks, but the nice part about the plug-in is that it makes some complex text calculations available using just calculations. For instance, one of the functions allows you to highlight words within a text field. (Unfortunately, this particular function currently works only on the Mac OS Classic version of FileMaker Pro.)
You can perform a similar action using layout tricks, but it’s so much easier with the plug-in. Another useful function is the SumText function, which allows you to create a calculation field that concatenates all of the text in all of the related fields of another database. Why would you want to do that? Well, FileMaker doesn’t have the ability to show a portal within another portal. For instance, say you have a database called Companies, a related database called Contacts, and another related database that hangs off Contacts called Notes. Notes are linked to contacts, which are linked to companies. If you want to print a report of a company’s contacts and show each contact’s notes, you would need to loop through each contact’s notes in a script, appending the related notes into a field within the Contacts database, which you would then display in a portal in the Companies database. Sounds like a lot of work, doesn’t it? Well, it is, and that’s why you might want to use the Troi Text plug-in to do the work for you.
There are about a dozen other functions available with the Troi Text plug-in. Check out the manual for a complete description of the rest of them, which provide the ability to sort the lines of text in a field or provide a list of the lines in two fields that are different.
The following example shows you how to use the SumText function. Since you’re primarily interested in learning about the capabilities of the plug-in, you won’t be using the Companies database, but only Contacts and Notes. Create a Notes database with the fields defined as in Table below.
Fields for Notes Database.
Now create a Contacts database with the following fields. Before you create the last field in the table, you’ll need to create a relationship between Contacts and Notes with the ContactID field as the match field on both sides of the relationship. The name of this relationship is “Notes_ContactID.” So that you can easily create notes from the Contacts database, specify the relationship to allow the creation of related records (Table below).
Fields for Contacts Database
Lastly, place a portal to the Notes_ContactID relationship on the layout and place the related Notes field in the portal. Then place the SumText field on the layout. Enter some notes into the portal and as you do, you’ll see that the SumText field fills in with the notes separated by returns. Keep in mind as you’re doing this that no script is being run. It is all happened as soon as you enter a note. While this kind of functionality is possible without the plug-in, it would require either a script or dozens of utility relationships, neither of which is a very attractive solution, and the use of utility relationships would place a maximum on the number of notes that could be appended in this way, whereas the plug-in doesn’t have that limit (beyond the limit of 64,000 characters per text field).
Probably one of the most commonly used script steps in FileMaker is the Show Message step, which displays a dialog of static text with up to three buttons. But this script step has many unfortunate limitations. The message in the dialog box is static and can’t be changed to show the contents of a field. The dialog box can’t have text fields in it, so you can’t let the user enter information. You are limited to a maximum of three buttons, and the far right button must be a default button.
Once again, there are non–plug-in solutions that get around these limitations. On the Mac, AppleScript can display a dialog box that is much more flexible than FileMaker’s Show Message, and it can include a text field that the user can enter information into. If you need more complex dialogs, there’s a free AppleScript scripting addition called Dialog Director that can provide more features. But if you want a cross platform solution, the non–plug-in solution most often used is the so called faux dialog box, which is a dialog box that is drawn on a FileMaker layout. This type of dialog can’t be dragged around the screen like a real dialog box so it feels like a kludge and isn’t recommended.
To the rescue comes the Troi Dialog plug-in, which provides many more features than the Show Message and “Show Custom Dialog” dialog boxes and better flexibility than faux dialogs. Your example script will be a progress bar dialog box, which will display the progress of a loop to the user. Building a progress bar has three steps. First you need to initialize the progress bar and display it to the user. Then, each time you go through the loop, you need to increment the progress bar. Finally, when your task is finished, you need to dismiss the progress dialog box. Create a database with the fields that are listed in Table below.
Fields for the Progress Bar Script Example
Now create a script that includes the following steps:
If you have a progress bar that has 100,000 iterations because it’s going through that many records, you probably don’t need to increment it with every record. You might instead increment it only when it’s reached 1 percent of the total (every 1,000 records). By using an If script step like the one in the script, you can do this. You first would need to calculate what 1 percent of the total would be, and then if the gCounter field is equal to an increment of that fraction, update the progress bar by that percentage of the total. You use the Int function to get a whole number in case the percentage is actually a fraction, although in the example (100,000 records with an increment every 1,000 records processed), this isn’t necessary.
Troi Dialog’s Progress Bar.
The Troi Dialog plug-in has many more possibilities. You can display dialogs with input fields, with password fields, and with standard dialog icons or even custom dialog icons. Given the flexibility of the plug-in and how useful dialog boxes can be in a system, you may come to believe that the Troi Dialog plug-in should be in every developer’s toolbox.
Although the scripting capabilities of FileMaker allow many powerful solutions to be built, there are a number of glaring omissions in what can be accomplished with it.Two of the most vexing limitations are that you can’t easily run a script when the user exits a field, and you can’t schedule a script to be run periodically.
The Events plug-in from Waves in Motion allows developers to get around both of these limitations, and also allows you to execute a script when a new record is created. As is often the case, the plug-in’s capabilities are possible with FileMaker alone, but are much more difficult, and don’t always provide the best user interface. For instance, you can run a script at field exit by disallowing the user from field entry, tying the field to a button that loops until the user has exited the field, and then perform the real actions that are needed. But this means that a user can’t tab into the field, and the interface of the continual pausing of the script is distracting. Performing a script when a new record is created, however, isn’t possible unless you only allow users to create records through your scripts.
One of the most useful examples of running a script when a field is edited is for complex validation that requires a script. For instance, perhaps the record reserves time in a conference room. Before the information can be accepted, you need to ensure that the conference room isn’t already reserved during the time requested. Such a confirmation may require that you perform a search and see if any records are returned. A validation of this sort couldn’t happen with a simple calculation, so running a script when the field is edited may be the only way to ensure that the information entered is valid.
Also, the validation dialog box provided by FileMaker is quite limited. Although you can display a custom dialog box when a validation fails, this dialog box is even more limited than the Show Message dialog box. You have no control of the buttons. If the validation isn’t strict, three buttons appear, Yes, No, and Revert Field, so you need to make sure that your custom message fits the available options. By using a script triggered with the Events plug-in, however, you can do anything you want, including using the Troi Dialog plug-in to display as detailed a dialog as you wish. For example, if a field is only valid if it is not empty and if it conforms to a calculation, you can display a dialog if the validation fails, but you can’t let the user know which of the field validations you’re employing failed because the message in the custom dialog is static. The only message you could provide would be something like, “This field must not be empty and much conform to criteria X.” But with the Events plug-in you can run a script and display a different dialog depending on the exact reason for the failed validation.
For automatically executing scheduled events, the Events plug-in provides two methods. The easy way is to use a database included with the Events package called “Event Manager.fp5”. Using this database, you can create events to take place once or on a repeating basis. All this database does is provide an easy interface to using the plug-in’s external functions, but if your needs are simple, this might be the best way to go.
The other method is to use the external functions themselves. For some of the features of the Events plug-in, this is the only way to make them work. For example, if you want a script to run when a field is edited, using the external functions manually is the only way. Such an event would be executed when the calculation that contains the external plug-in is evaluated. This can happen most easily within a validation calculation for a field, as you’ll learn in the example.
Waves in Motion also provides another useful database with the Events plugin. The database is called “oAzium Events Intro.fp5” and is almost as good as the PDF manual that is also included. Not only does this database provide examples of using the Events external functions, but it also provides a complete reference to all of the functions.
Take a Test-Drive
So now you’ll turn to the Events plug-in. The example of this plug-in will be to run a script when the user changes information in a field. Your script won’t actually do anything useful when the user exits the field, but it will provide a springboard for you to think about where you can make use of such abilities in your own solutions. It’s extremely simple to create an event that executes a script when a field changes.
First, create a new FileMaker database and give it a single text field called “Field”. Set the validation options for the field to validate based on a calculation and use the following calc:
Here’s a quick outline of what all those parameters mean. The first parameter, “script”, tells the Events plug-in that you want a script event. Other possibilities are an “open” event and a “close” event, which will open or close a database at specific conditions. Check out the manual for more information on these types of events. The second parameter, “FieldScript”, is the name of this event. The name that you give an event is totally up to you. In this case, the name isn’t important, because you won’t be referring to the name anywhere else, but when you create events to take place at a particular time, you can use other scripts to remove those events, and to do so you’ll need to refer to the events by name.
The next parameter, Status( CurrentFileName ), is simply the name of the database that the script is in. Because this is a single database olution, you can simply use the Status function to get the name. That way, if the name of the database ever changes, you don’t have to change the script to reflect that.
Next you provide the name of the script to run, “Field Script”. When FileMaker evaluates this calculation (which will happen when the field changes and it evaluates the validation calculation), this is the script that will be executed.
The next two parameters control when the event is run. In this case, you want the event to run when the validation occurs, so you pass an N for this parameter, which stands for Now. Other possibilities are to run the event at a specific time, periodically, or at some specified time after this. If you chose an option here that needed a time of some sort, you would use the last parameter for that.
Because you are running the event “now,” you pass an empty string for the last parameter. Now build the script that will run when your field is edited. Open up ScriptMaker and create a script named “Field Script” with the following steps.
Yes, it’s a pretty simplistic script, but it will demonstrate the plug-in. Go ahead and enter the field and type in pi. When you hit the ENTER key or click outside the field, you should get a dialog box that says, “You entered some text.”
Now click in the field again and type in 3.14159. This time you should get a dialog box that says, “You entered a number.”
The possibilities with this plug-in are endless, and bring up some things that many developers might think is impossible with FileMaker. Remember, if you ever hear that something is impossible with FileMaker, 99 percent of the time, that’s not correct.
The whole reason for FileMaker’s existence is to track data that you need to have available. Often, that data includes information that would be useful to see in a graph of some sort. Perhaps you are reporting the percentage of income for the company from all of the divisions and would like to see a pie chart that gives a graphical representation of the data. Or you’re tracking the sales figures for the last year and would like to see a chart of how those sales have looked each month.
Whatever the reason, charting is often a very useful way to get your mind around a great deal of data. But FileMaker includes no built-in charting capabilities. While there are tricks that can be used to fake it at times, these solutions tend to be difficult and require dozens, if not hundreds, of extra fields. Or you could export the data from FileMaker into Excel or some other program capable of producing charts, linking the two programs with AppleScript or ActiveX.
But why go with either of these routes when, by using Waves in Motion’s Charts plug-in, you can put the charts right in one FileMaker container field? The Charts plug-in gives you the ability to chart FileMaker data in any of nine different charts, from pie charts to bar charts and even Gantt charts. You’re going to examine a vertical bar chart.
Take a Test-Drive
The data you’ll use will come from a simple database that you’ll build that tracks the sales made by five different salespersons. Create a FileMaker database with the fields listed in Table below.
Fields for Vertical Bar Chart Example
You’ll use this database to create a bar chart of the sales made by each salesperson. Given how functions work in general, and external functions in particular, this format for the database presents a problem. A function can only reference information within the record the user is currently on (with the exception of the summary functions). However, because you want to create a chart that represents data across records, you need to create a way to get all of the data you want into a single record. If this were an actual solution, you would probably have a Salesperson database where you could store the total sales for each person and reference that information with relationships. For simplicity, you’re going to use global fields instead, and loop through the records, totaling each salesperson’s sales as you go. Below is the script for getting this information, which you will call “Calculate Total Sales”.
Once this script has been run, each of the gSalespersonXSales fields will have the total sales for that salesperson. Now that you have the information available to you from any record, here’s the script for actually creating the chart:
That’s a big calculation! The first line of the script simply calls your “Calculate Total Sales” script so that you can get the total sales information into a single record. Then your second script step uses that information to produce a bar chart based on the data.
The first function of the Set Field step initializes the bar chart. The first parameter tells the plug-in that you want to draw a bar chart. The second specifies which database the chart will appear in and the third parameter specifies the field. This field should be a container field, in your case, a global container field. The fourth parameter to OzCh-Init is used to specify which record the chart should be drawn in. If you weren’t using a global field, you would probably use Status( CurrentRecordID ) to specify the current record. Because you are using a global field, you use a “g” to specify that it doesn’t matter which record since you are using a global field that is shared among all records in the database. The last two parameters of OzCh-Init specify how large the chart is, the first number representing the horizontal pixels wide and the second the vertical pixels tall.
The next function lets the plug-in know that you want a background color for your chart, in this case gray. The three numbers in parenthesis represent the red, green, and blue values (that’s what the “rgb” stands for).
Next, you provide the data points for the chart, using your global fields, which were filled in from the previous script. At this point, the plug-in makes a slight departure from the normal procedure of separating parameters with the pipe by separating each data point’s information with the pipe, but separating the data for each point with the pound symbol. This makes sense, because otherwise the plug-in wouldn’t be able to determine where one point ends and another begins. Each parameter for the points includes the value for that point, the color for the bar, the label for the bar’s value (which in this case is the same as the value for the point), and the label to appear below the bar to indicate which data point it represents.
Where before you specified the background color as an RGB value, here you use the Chart’s built-in constants of a number of colors. The Charts plug-in provide built-in constants for all the primary and secondary colors, as well as for black, white, and shades of gray.
Once you have provided the data points to the plug-in, you move on to other information that customizes the look of the chart. You set the lines for the x and y axis of the chart to purple, set the size of the lines to a single point, and set the axis and grid of the y axis to 100. This means that the labels of the y-axis will appear for every 100 values and that the grid across the chart will also appear every 100 values.
Next comes a number of calls to the OzCh-Options function. The first one tells the plug-in that you want to use blocks for your chart, as opposed to “Shadows”. Then you specify that the chart should run from 0 to 500, the point size for the data should be 10 points, the color for the data points should be green, the label font 10 points, the label color dark blue, the axis font size 10 points, and the axis font color dark blue.
Although this example hard-codes everything except the data points, keep in mind that you can use information from your data to specify any of these parameters. For example, you hard-coded that the maximum on the y axis is 500, but you could have instead calculated what your maximum data point is, added perhaps 10 percent or so to that, and made that the maximum of the y axis.
If you’ve created your own version of the database, populate the database with a dozen records or so and run the script, or open Chart.fp5 and click the Chart Data button. You should see something similar to Figure below.
Chart created with Waves in Motion’s Charts.
You’ve only barely scratched the surface of what is possible with this plug-in. In addition to bar charts, just about any other chart you might wish to create is possible, such as line charts, pie charts, or even Gantt charts. Tinker around with the example database, changing parameters here and there, and see how many funky charts you can come up with.
While FileMaker gives you a great deal of control over many aspects of the system via the ScriptMaker, there are a number of tasks that simply have to be done manually. One of the most tiresome of these tasks is changing the password across multiple databases. The most that ScriptMaker can do is to bring each database to the front and display the Change Password dialog, but most multidatabase systems have the same set of passwords across all the databases. It would be nice if you were able to enter the new password a single time and have FileMaker take that information across all of the databases.
In addition to that functionality, Dialog Magic provides automation for many of the FileMaker dialog boxes that aren’t available from within ScriptMaker.
Before the release of FileMaker 5.5, it was common to use Dialog Magic to reset serial numbers after importing records. It also allows you to set the name and location of an export file and set the name and location for copies and clones.
While the plug-ins you’ve learned about so far offer features to enhance the user’s experience, Dialog Magic is more geared toward making the developer’s life easier. The ability to set the name and location of copies and clones and the ability to reset the serial number greatly simplify the scripts that developers need to write when upgrading a system.
Using the Dialog Magic functions is quite simple, and probably the most common use (since the release of FileMaker 5.5) is to globally change the password in all the databases. There are two things to be aware of when using the DM-Password function: First, Dialog Magic can only change the password that was used to open the database. This makes sense, because the Change Password dialog box also has that limitation, and in fact, if that limitation didn’t exist, there would be a severe security risk. Second, after calling the DM-Password function, you need to immediately use the Change Password script step. DialogMagic will then automate the process of inputting the original and new passwords.
Take a Test-Drive
The sample database for this plug-in is very simple. There are three fields: gPlugin, to accept the value returned by the DM-Password function; gOriginalPassword, to input the original password; and gNewPassword, to accept the new password. As is the custom with the examples, the script in the DialogMagic.fp5 database (found on the CD) doesn’t have any error checking, such as ensuring that the plug-in is installed. The database has a single password set to “User”. To try out the plug-in, ensure it’s installed correctly, double check that the current password when you open the database is “User”, enter User into the gOldPassword field and any password you like into the gNewPassword field, and click the Change Password button. Then go back to the Passwords dialog box and see that the password has been successfully changed.
This is the script that the Change Password button calls:Set Field [ gPlugin, "External( "DM-Password", gOldPassword & "|" & gNewPassword )" ] Change Password
To change the password across all of the databases in a multi-database system, each of the other databases needs to have a script with the Change Password script step in them. You don’t need to use DM Password in each of the databases, only the first time. After a few seconds, DM-Password’s call expires. Note that if you’re running a demo version of Dialog Magic, the word “DEMO” will be added to the password when you use the plug-in.
Given how integral the Internet is to computing in the 21st century, tying FileMaker to email, especially with a contacts database, makes perfect sense. And FileMaker does provide rudimentary email capabilities with the Send Mail and Open URL script steps, but both of these require another program to actually compose and send the email, and both have limitations. Send Mail only works with some email clients, and Open URL can only send email with a small body because the entire URL must be less than 256 characters.
In comes SMTPit, which allows you to send email directly from FileMaker. Comm-Unity Networking Systems also publishes POPit, which enables the receiving of email within FileMaker, so conceivably, with these two plug-ins you could create an entire email client application within FileMaker. This would have the advantage of allowing you to keep your contact information in a single place (rather than once within FileMaker and again within your mail client’s address book).
Take a Test-Drive
The sample database on the CD is quite a bit simpler than that. To use it, you’ll need to fill in information about your email account, such as the server address, your ID on the email server, and your password. Table below contains a complete list of all the fields in the database.
Fields in the Email Database Example
Surely the reason for many of these fields is obvious, so there won’t be any detail about the FromAddress, ToAddress, Subject and Body fields. The gPlugin field serves the same purpose it has throughout your plug-in explorations to act as a receptacle for anything returned by the external functions.
The first field, SMTPHost, is the address of your outgoing email server, such as “smtp.mac.com” or “mail.yahoo.com”. Many SMTP servers require authentication these days, and if yours does, you’ll need to set the AuthenticationType to the appropriate type, such as Plain, Login, or CRAM-MD5. If your SMTP server doesn’t require authentication, use “None”. If you know that your server requires authentication but are unsure of the type, try Login first. If that doesn’t work, you can try the other two. If authentication is required, then the UserName and Password fields are also required. Normally, the UserName is the portion of your email address before the “@” symbol.
After you fill in the host and authentication information, you can fill in the more general fields, specifying who the email is coming from, who it’s going to, what the subject is, and what the body is. If you have more than one email address, try sending from one address to the other. Otherwise, you can use the same address as the FromAddress and the ToAddress.
When all the information is filled in, click the Send Email button. Then go to your email program to check your email and you should get the message you sent.
Here’s the script that actually sends the email:
Fairly straightforward, wouldn’t you say? After using a series of external functions to set each piece of information from the fields, you simply send the email.
In most systems, the SMTPHost, AuthenticationType, UserName, and Password aren’t going to change often, if ever. You can make things easier on yourself by storing this information in global fields, but SMTPit also provides another way. In the configuration screen for the plug-in, you can set many defaults, including these pieces of information. Unless you specify them to be different, SMTPit will use those settings as defaults.
SMTPit configuration dialog
SMTPit provides a host of features to assist in sending emails, including the ability to send HTML-formatted email and to include a header and footer in every email sent. Many of the features are geared toward sending bulk email. Go ahead and take a look at the documentation to find out more information.
24U’s Preferences+Globals Plug-in
24U’s Preferences+Globals plug-in falls under the heading of “Yes, you can do this kind of thing with FileMaker alone, but it sure is easier with this plug-in.” Variables are invaluable to programming with FileMaker, but FileMaker doesn’t actually provide a variable tool. The closest thing it does provide are global fields, but these tend to multiply quickly, so that a database may have dozens of global fields to handle variable chores, making the field definitions dialog unwieldy.
One of the features of Preferences+Globals is that you can define global variables on the fly within a script. A common use for this kind of functionality would be for a counter field. Many FileMaker solutions will have a global number field called something like gCounter that is initialized in loops and incremented through the life of the loop. But why take up a field for something useful on such a temporary basis? With Preferences+Globals you can define a global variable within the script to handle this chore.
Take a Test-Drive
The sample database from the CD, Variable.fp5, does just this. After the user enters a number to count to, the script "Use Counter" simply creates a loop that counts to that number. Your database has only a single number field, LoopMax, to allow the user to input data into, and a global text field, gPlugin, to accept the plug-in’s result. Here is the script code:
The first line of the script stores a value of 1 into a global variable called Counter. You then enter a loop, exiting when the value in the variable Counter is equal to the value entered by the user in the LoopMax field. If you haven’t exited the loop yet, then the next line increments the variable Counter. The attraction of this type of loop using a global variable rather than a global field is that you have created the variable within the script itself rather than having to create a global number field within the database structure.
If you decide to test this script, be sure to enter a small value for LoopMax, as each time an unregistered copy of Preferences+Globals executes one of its external functions, a dialog box appears reminding you to register the software, and because the loop has three calls to the plug-in, you’ll get three of these for each iteration through the loop.
The Preferences+Global plug-in also allows you to store the contents of a field into a preference file and read the contents of that preference file. The location of the preference file depends on the platform that the plug-in is being run on. On a Windows system, the preference file is saved in Windows Profiles username Application Data 24U24u Preferences+Globals Plug-In. For Mac OS Classic it’s saved in Hard Drive:System Folder:Preferences, and on Mac OS X it's in /Users/ username/ Library/ Preferences/.
Given how FileMaker can integrate with email using the SMTPit plug-in already covered, it would often be useful to use FileMaker to email a report in PDF format. Strictly speaking, this is possible, but if you want to use FileMaker without any help, your users are going to have to do some of the work because FileMaker has no way to change which printer a print job is sent to.
As you have probably already guessed, Productive Computing’s Change Printer plug-in adds exactly this sort of functionality to FileMaker. With it you can get the name of the currently selected printer as well as change which printer is selected. This means that if you want to send a PDF file of a report, you can generate the report, store the current printer into a global field, change the printer to the PDFWriter, print the report, and then change the printer back for the user.
Once you have saved the PDF, you can then use SMTPit to email it as an attachment.
Take a Test-Drive
This plug-in is probably the simplest of those covered here. It includes only three functions, and one of those is the version function. To demonstrate this functionality, you’re going to again create a simple database with only a single field. Your sample database will go through the motions of finding out what the currently selected printer is named and storing that in a global text field. It will then change the printer to Acrobat PDFWriter, which is the name of the PDF print driver on your computer. If you’re not using Acrobat’s PDF print driver, fear not. You’ll still be able to see the functionality of this plug-in, although you will need to have at least two different print drivers in order to do so. If you’re missing the Acrobat PDFWriter printer driver on your system, just replace the text “Acrobat™ PDFWriter” in the following script with the name of one of your own printers, preferably different from the printer that you normally use.
Create a database with two global text fields, the first called gPrinter, and the second gPlugin. Then create a script with the following code:
You can’t get much simple
File Maker Related Interview Questions
|Management Information systems Interview Questions||Software Engineering Interview Questions|
|File net Interview Questions||Data analyst Interview Questions|
|Hadoop Distributed File System (HDFS) Interview Questions||Linux File Systems Interview Questions|
|Excel Data Analysis Interview Questions||Asp Dot Net Database Interview Questions|
All rights reserved © 2020 Wisdom IT Services India Pvt. Ltd
Wisdomjobs.com is one of the best job search sites in India.