Unlike most other applications in this general category. Any edit box, drop down list, pop up menu, etc. must refer to a field defined in a table. Defining an "unbound" control is not an option.
But you can specify global storage for the field you use for that edit box or other data entry control. Fields with global storage store a single value for all records in that table. The global field can be directly accessed from all layouts in your file and from any script your create in your file. The values are accessible when a script enters find mode so you can have your users enter data into a global field and then the script can use that data to build criteria used to perform a find. In a networked database, each user get's their own "virtual copy" of any global fields. Any changes they make to data in a global field will not be visible/accessible to other users. When they close the hosted file, the value in global field fields revert to the values last entered into them on the host computer.
The grid you show at the bottom of your example would be created in FileMaker by using a Portal to a related table. This is something you can look up in FileMaker help and any training resources you may have access to in order to learn more about it. (If you've used MS Access, a "portal" functions very similar to the sub forms and sub reports used in that product.)
Thanks, it works like I suspected. Some things appears to be very limited, but it's the price you have to pay.
If I understood well, portals are only allowed for subordinated tables, not for top level ones, right ?
Define what you mean. What is the difference in terms of the relationships?
A portal is intended to list one or more related tables. If the relationship is valid, you'll see the related records from that table. Most, but not all, portals list multiple records so they are usually used with a one to many relationship.
If you have a many to one relationship, you have only one related record and in this case, while a portal will work, it will only list one record as you only have one related record to display in it. In such cases, you can add the fields from the related table occurrence to your layout instead of using a portal.
If "table occurrence" is a new term. See this thread to learn more as it is a key aspect to how the relationships in manage | database | relationships control the function of a FileMaker database: Tutorial: What are Table Occurrences?
Suppose that I have just one table. Is it possible to display this table using a portal instead of table view ?
Yes you can as you can relate a table to itself by making a second occurrence of the table in manage | database | Relationships and linking them. You base the layout on one occurrence and the portal on the other. The default relationship operator is =, but you can double click the relationship line to get a dialog where you can specify other operators such as inequalities or the cartesian join operator (X) which enables you to relate any record on one side of the relationshp to all records on the other.
But I might very well use a list view layout in place of that table view. It depends on what kind of layout design you are implementing.
Thanks a lot. Now I have to evaluate other aspects and see if porting one of my projects to Filemaker will worth the effort.