Quickie Demo for fun

This is a little demo file that does something very simple. It takes a value, searches for it in list B, returns the corresponding value in list A. Handy for simple 1 or 2 word lists, where you have the ID list in the same order as the list of actual values. Sometimes you need to hunt 1 list against the other to get an ID or other value.

Just tossing this out there for fun. Maybe it's handy. It's not going to work for every situation but it's lightweight. Enjoy

Demo file

On the Fly Semi-Dynamic Value List (Demo File)

Why I created this DEMO?

We have a lot of ways to do value lists, YET I was experimenting with another way. I was feeling lazy about building a TABLE to store yet another small set of values and I didn't really want to do it with a typical hard coded value list . I guess I'd say this is a semi-dynamic / semi-hardcoded value list method. It still requires telling the solution what the values are (as you would via the indexed field method and adding records or also by hard coding them in the standard FM create Value Lists feature). This is somewhere in between cause you can script the values and obviously anything you can script is pretty dynamic. With this method you do use the indexed field option to create your Value List/s, but it doesn't involve multiple tables. This is a hack. I'm really not sure if this will play well in real world situations. I haven't had the opportunity to use this yet. That's kind of why I'm doing the demo, to see how it works and have a reference for when I might want to pull this technique out of the bag. AND maybe you will do something really cool with it that I would never think of and come back and tell me about it. :)

What's going on with this DEMO?

Getting to know this demo file will show you how to create a value list, based on a field index of a single record.  Again, maybe this is typical and everyone's doing it already but I haven't seen it out there, so here it goes, even if only for my own experimentation. :)

What are the moving parts in this demo?

1 - Table (Settings) with one record and some value list fields.
1 - Table (Contacts) just some data to have fields with value lists on.
1 - Script ON OPEN it sets it all up.
1 - Script that loads the value lists ... "Load value lists".
1 - Layout to display our records and value lists (Contact List).
1 - Layout for the interface (in this case it's this About This demo layout).
2 - Fields in interface table for each value list. To extend this you would need fields for each value list, instead of entire tables for each value list.
2 - Value Lists based on the above two fields in this demo "BusinessType" and "FavoriteThings".

Why is this cool?

I think this is cool cause you can dynamically SET a value list with scripting to be what you want. YES, it involves maintenance of those scripts but it also allows you to skip having a table if you don't really need it and with some planning you could set up lists fairly dynamically. Depending on what you're trying to do. This is definitely not the "right" normalized way of doing things but there's always a time and place for a short cut and perhaps this is a useful one.

How to get started with this file?

Click on the link (upper right) "Contact List", notice the value lists that appear under "Business Type" and "Favorite Things". Looks at those in the Manage --> Value Lists under File menu. Review the Load Value List script and check out the tables and fields. It should all start to click from there. This demo assumes you know a bit about FileMaker development otherwise it might be a little confusing sorry...

Demo_OnTheFlyValueList.fp7

Thanks for checking out this demo!

Peek A Boo Body Report Technique/Demo File

I have been meaning to post a demo of this technique for a while now. I haven't come across other demo's using this technique, not to say it's not out there but here it is. I hope someone finds it useful.

What's going on with the Demo?
Use a single layout to display a report that shows Contact data in many different ways. We are all familiar with sub-summary layout parts displaying in browse mode (YAY), but the twist here is that we don't have a BODY LAYOUT PART on the report. YET this report can show or hide detailed data that would typically be shown in the body part of a report layout. The simple trick is to change the BODY layout part to a sub-summary based on the ROW ID. When we want to SHOW the body, we sort by the primary key and viola you have a PEEK-A-BOO BODY layout part. Create a couple or more filters to change the way the report is viewed and create as many sub-summary parts to match sorts. Adjust the layout so it looks good when sorted various ways, it is a bit compromised but pretty neat.

What are the moving parts in this demo?
1 - Table (Contacts)
1 - Layout with 4 Sub-summary layout parts (Sales, State, City, ID).
2 - Global fields for solution users to set the REPORT STYLE and the REPORT FILTER, with script triggers attached to run ON OBJECT MODIFY
1 - Script "Apply Report Style, Filter and Display the Report" triggered from the above global fields

And a little bit of conditional formatting to make it all look nice.

Why is this cool?
Because you can have 1 layout that does a ton. This means a single layout to maintain over time. Somewhat scalable, you can always add more sub-summary layout parts to display/group your found set of records based on different types of fields, or even calculated fields.

How to use the report.
This demo file defaults to all the records in this sample database. Toggle the Report Type from "Summary" or "Detail" AND then try the Filter options, in combination with toggling the Report Type back and forth from Summary and Detail. This should give you an idea of how the report works. Crack open the layout and see how that works.

Demo_Peek-A-Boo_Report.fp7

Server Side Scripting With A Dedicated Execution File

I am still wrestling with a 100+ legacy database solution. I haven't been able to consolidate or re-write yet but have been slowly, version by version starting to deploy new Filemaker features. One thing I did, was set up a Filemaker file who's sole purpose is to call and execute server side scripts.

Now that we have script triggers firing off, God knows where (on file open, on layout load, on object enter... for example), you really have to make sure that stuff isn't firing off for a server side script and you don't always have time to review all of the dependencies of executing scripts from a given database file. If you do and do not do your homework, you may be calling incompatible script steps which could hang your server script or create loads of errors in your logs.

I wanted a simple, fast and safe way to call scripts across the 100+ file solution and be sure that on window open scripts didn't fire. Typically, the on file open scripts tend to do things like call custom menu sets or other non-server-side script compatible steps. So, knocking those out of the picture this way was a big plus.

Setting up my server side scripts to run from the dedicated execution file, each call remote scripts through out the solution, seems to be doing the trick. When performing REMOTE scripts the remote file ON OPEN scripts don't run.

When writing the worker scripts, that live in the remote files, I will typically create a clean layout - one that that has no bells and whistles attached to reference.

I also like the fact that you can go to the dedicated script execution file and see all the various server side scripting routines at play or in development. Also, a good place to document the scripts and organize in folders. I like to use a PRODUCTION folder and TESTING folders. It's also cool when you have more than one developer. Using a consistent naming scheme for server-side-scripts located across the 100+ files in the solution will make it easy to locate them in a pinch on a file by file basis or even from a DDR perspective.

Not everyone would want to have an extra file in their solution for this purpose but in this use-case I have 100+ what's 1 more, to me nothing. It's kind of nice quick way to move ahead when working on a massive system that sprawls over a decade of FM versions and code. It does require following a development process for server side scripts:

1. Use a naming convention for your worker scripts, so you can find them
2. Always run your worker scripts off lean utility layouts that don't have script triggers
3. Make sure you aren't calling other scripts that will do incompatible script steps or incidentally reference layouts that call scripts that do incompatible things
4. Create a script in the dedicated execution file to call/RUN your main worker script

I'm working on a new server side script and was reminded again that this method I had come up with a while ago, does seem to be working well. I avoided some headaches of having to review what on open routines were doing that could cause me pain and it actually saved me some time. An idea I tried a while ago is paying off today.

Playing with 0 as Parameter in the Date function

I recently came to understand how using 0 in the month or day parameter of the date function can be pretty handy. I admit this is a basic idea to many but if you don't use it I figure this insight might get the wheels turning.

This example shows how to calculate the last date of the month from any supplied date.

Let ([

    // Put your date or date field here
    theDate = "10/30/2010";

    // Get last date of month base on theDate
    lastDateOfMonth = date ( month(theDate) + 1; 0 ; year(theDate))
];
    lastDateOfMonth
)

or this example which results in the last date of the year prior...

date ( 0+1; 0; 2010) // last date of year for year 2010

Notice the 0 and how it's behaving when used inside the date function. I realize grabbing the last date of any year is easy to calculate in other ways, it's not the most intriguing use case but I wanted to demonstrate the behavior of using 0 as month.
Good stuff. So I plan to play with 0, + and - in functions more often.

Hello Blogger

Well, here I am trying blogger now. Still trying to find the most comfortable blogging space. I hope to post mostly Filemaker things here but who knows. I seem to change my mind often enough.

Today was a good day, I'll start with that