Custom Button Actions

Overview: What Are Button Actions?

Button actions let you add your own buttons to the calendar. These buttons run your own FileMaker scripts and are a great way to extend the calendar's capabilities.

Each source gets its own action buttons, and our sample events table comes with two: one to jump to the event's record in its own FileMaker layout, and another to just show a simple dialog.

Reveal the actions drawer by clicking the gear icon in the lower right of the event's popover. You can add as many custom actions as you'd like: your list of actions will scroll if it exceeds the length of the drawer.

Here's an overview of how the work along with some tips for extending our example actions and making your own:

https://youtu.be/N8TtttLL5AY

How to Create Your Own Actions

You'll define your action buttons by editing the script "Load Source Settings at Startup...". For each source in that script you'll see a variable called "$$sc_CustomActions". The definition of that variable declares the names of your action buttons and the names of the scripts they should run.

This takes the form "Button Name<comma> Script Name". Here is the $$sc_CustomActions definition for the popover shown above:

List (
"View Event Record, Go To Event Record From WebViewer";
"Sample Custom Action, Custom Action Example" ;
""
)

This means that DayBack will draw an action button named "View Event Record" and when it's clicked it will call the FileMaker script named "Go To Event Record From WebViewer". The third item intentionally left blank is a "Watch For Event Changes" option. This can be set to True or False. In most cases this is unnecessary and will complicate your scripts so we recommend to leave the third parameter blank. An explanation of this feature is lower in this article.

Note that you can change the text at the top of the drawer ("Call your own scripts") to anything you'd like by adjusting the calendar's translation file.

Add Icons and Colors to your Custom Action Buttons

You can change the appearance of your Custom Actions buttons by adding CSS specific to those buttons. The way this works is by tagging your button with a new class, and then adding CSS for that class. Here're how:

Tag your button with a class. Revisit the script when you've described your custom action button: that's the script "Load Source Settings at Startup...". To add a CSS class to your button, simply add an additional parameter after the name of your button's script. So the buttons might look like this:

List (
"View Event Record, Go To Event Record From WebViewer, SomeClassName";
"Sample Custom Action, Custom Action Example, AnotherClassName" ;
""
)

Note that you can tag a button with more than one class by separating your class names with a space.

Apply some CSS to that class. Once you have a class name for your button. add some new lines to DayBack's CSS to style the button. If you've never edited the CSS before, you'll find instructions here. Here is some sample CSS to make a button blue and give it a check icon:

.SomeClassName .btn {
background-color: blue;
}
.SomeClassName .btn:hover {
background-color: gray;
}
.SomeClassName .btn:active {
background-color: black;
}
.SomeClassName .btn::before {
content: "\f00c";
font-family: FontAwesome;
padding-right: 5px;
}

Icons. You can specify icons in CSS by selecting something from the FontAwesome icon set as you can see in the .btn::before example above where we chose the icon "\f00c". To find an icon, visit https://fontawesome.io/cheatsheet/ and select an icon (DayBack has access to *most* of these). You'll see the unicode for each icon to the right of it like "[". To use that icon in CSS, add a leading slash and just take the 4 digits starting with the "f" in every case. So in this case it would be "\f2bc".

Tips for Writing Your Action Scripts

Take a look at our example script "Go To Event Record From WebViewer". That shows you the variables you'll have access to.

Notice also how you can call the script "Find Event by ID (ID)" to jump to your event by passing in the variable $eventID as a script parameter.

The scripts you call with custom actions will have access to a few local variables you can use to find events and manipulate them. These variables will already be declared when your script starts to run:

$start: the starting timestamp of the event you clicked on. For example "10/28/2014 12:15:00"

$source: the number of the source from the event you clicked on. For example, if the event was mapped on the "Source No 1" layout the $source would be "1".

$eventID: the primary key (unique id, often a serial number) or the event your clicked on. This is the from the field specified by "id" in the calc "DBk_WebViewerSource".

$end: the ending timestamp of the event you clicked on. For example "10/28/2014 12:15:00"

$allDay: true or false if the event is an all-day event (an event with no start time).

Please note that the $start and $end parameters will be in whichever date format you are using in the calendar. If you have left the date format settings in their default state this should be your local date format.

Watch For Event Changes

This is the third option when creating a custom action in the "Load Calendar Settings" script. Generally this will be left blank. If this is set to True it will signal the WebViewer to pass back a $queryID parameter to your custom action script. This way each process gets it's own ID. This was also intended to be used for signaling when an event might be updated but we have better methods for that now. Specifically you can look at the "Close Event Window & Refresh Calendar" for updating an event in the WebViewer once it has been edited in a FileMaker record.

Need to run scrips in web apps instead of FileMaker Scripts?

You can use your FileMaker scripts to call urls in other apps--as we do in this example linking DayBack Calendar to your wiki--or you can use JavaScript to talk directly to other apps: Check out JavaScript Custom Actions.

Can I remove the custom actions cog/button from the popover?

This can be accomplished by adding a few lines to your CSS file as described in our CSS documentation here.

Event Actions: run scripts without a button

You can also call scipts based on user actions like clicking on an event or hovering over an event. More here: Event Actions