Are the blank boxes under the chemical abbreviations: Are those to list the percentages or are they to allow the user to input percentages mannually?
Filemaker is more flexible if you can keep the number of columns static and simply add more rows. If you can work with a layout where the data looks like this:
It gets a lot easier to implement as you can simply add more records as you need more rows. This is particularly true for data entry. For reporting purposes, there are ways you can get the format you want once the data has been entered.
How would I go about doing the whole thing?
I'm not sure from your posts, what you mean by the "whole thing". :smileywink:
For starters, I'd define at least three tables: tests, materials and Measurements.
Tests::TestID = Measurements::TestID (Enable allow creation of records... for Measurements)
Tests::MaterialID = Materials::MaterialID
Define a portal to Measurements on a Test layout
A field in Materials can list the elements for which measurements will be recorded for that material.
Tests::MaterialID can be formatted whith a drop down that lists materials in a two column value list.
A script trigger on this field can trigger the following script:
Set Variable [$Elements ; Value: Materials::Elements ]
Set Variable [$TestID ; Value:Tests::TestID
Go To layout [Measurements]
Set Variable [$I ; Value:1 ]
Exit Loop If [$I > ValueCount ( $Elements ) ]
Set FIeld [ Measurements::TestID ; $TestID ]
Set Field [Measurements::Element ; GetValue ( $Elements ) ]
Set Variable [$I ; Value: $I + 1]
Go To Layout [original layout ]
with this method, you'd store your list of elements vertically in one field with a return after each element name or abbreviation. One such field migh look like this in the Materials table:
With that approach, selecing a material will populate the portal with a list of elements for which you will be recording measurements.
See if you can get this part, data entry, working and then we'll look at how a report might list this in a single horizontal row.
Assuming that you're happy with using repeating fields, the solution would be that:
- Make a table with report templates: Material and a repeating field that lists all elements that need to be reported for this materail.
- Make a table with reports. Each report will have a Material field, a repeating field to list elements and a repeating field that lists results for this element.
- Make a relationship Report::Material = Template::Material.
- Set the Report::Elements to lookup Template::Elements.
Now when you add a new report and select its material, you'll get all elements that need to be reported for this material.
Most developers frown upon using repeating fields for data. In this case the solution would be more complex:
- Add two more tables: Template Element, Report Element. These tables need to be linked to Template or Report respectively and their records will take the place of repeating fields.
- Write a script that fires when you select another material in Report and make it to delete existing report lines and then go to the selected template, find all its lines and for each create a new record in the Report LIne table.