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