I have a "date" field in a table. I would like to make a drop down menu where all the years go by and selecting a year will only show me the records of the year in selection. What is the best way to proceed?
The easiest? Have a field "myYear" = Year(myDateField).
Use it in a value list. Then have a new field (global storage) set to display the new value list. You must "trigger" when the drop down menu is changed. Have it call a script to FIND
Enter Find mode
Set Field (myDateField ; myGlobalDate)
If you need help with more details or terms, report back!
thanks to Beverly! I had set up the fields as you suggested me, but I thought they were redundant. If the search was possible to use the calculation I would have avoided the "year" field of the date. You're always kind.
Just searching by year is the script (or manually). The calculation was to get the List of years from which to search. Did you not need that? or did you have another method to make this list for you?
For me it is always interesting to see solutions and at times I imagine solutions without knowing if the possibilities exist. No problem I did as you wrote, but at first I had imagined that I would only include a global search field, but I was not able to avoid the "year" (year Get (date)) field as you did and this both for the list of values and for the search. It's not worth complicating things. My question was almost didactic to me.
I would not like to create redundant fields as in the "year" case, but then in the two script scripts and value lists I would not know how to do and what counts is that it works, so it's okay as you suggested.
You will need to SET the values for the value list. I used the calculation to gather ONLY the years that might be in your current records. Another calculation (using a custom function) might get you a range of years (regardless of what may match your records or not). Another calculation might use ExecuteSQL() to gather the DISTINCT list of years.
Even if there is a scripted Set Field (with one of the calculations), the value must be somewhere calculated to be used in the value list. Then the selection field uses that value list and another script triggers the find.
So "redundant" is not really what is happening if we must have a field to "store the values" (calculated or scripted) and another field to temporarily store the selection (which triggers the find script upon change).
It's the way that value lists work in FileMaker. I believe there may be suggestions to have $var/$$var to store values for such a selection list. But for now, they are:
2 dynamic-gathered-values (based on field contents with the option for conditional/relational values)
I think it is absolutely logical and competent what you say. As I wrote, I made a hypothesis without sufficient elements.
I have also speculated a nested portal some time ago ... but it does not exist. You suggested me well.
Retrieving data ...