This is called a "conditional value list" If you set up the correct table where each record is an available rehearsal time period for a specific date, then such a value list will be possible to set up.
Here's some basic info on conditional value lists to get you started. Feel free to post back with questions if you still aren't sure how to set this up.
Forum Tutorial: Custom Value List?
Knowledgebase article: http://help.filemaker.com/app/answers/detail/a_id/5833/kw/conditional%20value%20list
Thank you for your quick response Phil!
For clarification of the set up, I am going to need to solidify dates in a table instead of being able to let the user pick any date. Is this what I am understanding? And thank you for the demo file, that helps alot.
Conditional value lists take their data from a table and a relationship is used to control what values are listed in the value list.
Thus you'd set up a table of your rehearsal times that might look something like this:
9/29/11 8 - 9 am
9/29/11 9 - 10 am
9/30/11 8 - 9 am
9/30/11 11- 12pm
Using the conditional value list, selecting 9/29/11 produces a list of just the first two rehearsal times. Selecting a date of 9/30/11 produces a list of the last two rehearsal times.
That makes perfect sense. Thank you for the clarification.
I hope you will allow me to ask one further question of you. If only one person can be assigned to each time, once that time has been chosen, is there a way to remove it from the Value list so that it is no longer seen for future records? In order to avoid double booking a time.
I was expecting that one. It's a natural extension of the basic concept here. It's called a "dwindling value list" as the items previously selected get automatically omitted from the list so the list of available values dwindle as more and more are selected.
There are two basic ways to get a value list to "dwindle". A triggered script can set a value in the table of values that then causes that record to be filtered out of the list. The other option builds a list of selected values on the other side of the relationship and a not equals operator uses that list to filter them out.
The first option is easier to explain, but takes more effort to maintain the list when you change a value selection--taking one value off the list and putting another back into it. The second option updates to add/remove available values automatically if you can set it up with a unstored calculation--which isn't always possible to do.
Here's the basic idea:
If you have this relationship:
People::RehearsalDate = SessionsByDate::RehearsalDate
Change it to:
People::Rehearsaldate = SessionsByDate::ReHersaldate AND
People::constOne ≠ SessionsByDate::Selected
constOne is a calculation field that always returns the value 1. Selected is a number Field. An OnobjectModify (pop up menu) or OnObjectSave (Drop down list) trigger can then run this script to mark a date record as "selected":
set field [RehearsalDates::Selected ; 1 ]
This uses a different relationship, such as:
People::RehearsalID = RehearsalDates::RehearsalID
so that you have a link to one specific record here.
The catch here is that after first selecting one rehearsal date and then changing it to a different selection, the first selection is not automatically returned to the list. That would take additional scripting to handle.
Thanks again Phil!