A portals name , if it has one, is its Object Name. You can give it a name in layout mode.
I tried that as well, but then when I tried using Get (Active Object Name) I get a null. Figuring it was because the field in the portal was the active object and not the portal itself I tried naming the field in the portal. That seems to work as far as getting the name, now the issue is putting that in the Data::serial number field.
This should be easy, BUT, in order to have the columns there are multiple portals, each with its own relationship. i.e. The BP form is related to 6 different TOs of the data table called BPdata1 - BPdata6. So I can use set field BPdata1::serialnumber to Get (active object name) and it works for the first column setting the serial number for that particular portal row. But when run on the other columns it always sets the first row of the first column.
One thing you can do to simulate a horizontal portal is set the initial row to something other than 1 for each 1 row portal.
Another way to do it is to create portal table occurances and create relationships for them to different display keys.
I created a horizontal scrolling effect once by having a set of calculated Global fields and each portal (actually they were just related fields) linked to a particular display key. Then my scroll buttons manipulated the first display field and the rest calculated from there.
It worked because I was able to calculate (though rather complex) each subsequent key based on the first portals key
I wasnt thinking that the object name would be very useful but its there.
What exact method did you use to implement your horizontal portal?
Am I correct that the location of the cursor/focus needs to determine the record that will be modified by your script?
Yes, I would want to set the serial number of the Data record being modified to either the portal name (or the Form::SerialN field above that portal).
I guess this is more of a table than a horizontal portal. Sorry for the misspeak there. For this particular for there are 6 separate portals with 17 rows each. Each portal has its own relationship to its own occurance of the data table. So there is:
BP!Data(1...17) BP2Data(1...17) etc
I wanted to be able to enter data in the next column without having to fill in all of the rows in the previous columns. In most cases the number of test points is not equal to 17, so for each sample there could be less that one full column or multiple columns plus a partial column.
How did you name the individual SerialN fields "above the portal". What makes one different from the other?
Get ( ActiveFieldTableName ) will return the name of the portal's table occurrence. Since this will be different for each portal, that should suffice to tell which portal you are entering.
There's another approach you may want to consider:
Define a global variable such as $$SerialNumb
Have an OnObjectEnter script trigger pass the desired serial number value as a script paramter to this script:
Set Variable [$$SerialNumb ; Value: Get ( ScriptParameter ) ]
Then define your portal table's serial number field to use the variable to auto-enter the contents of the global variable.
I've used this trick when I had filtered portals on different tabs of the same tab control. The value entered into the variable was then auto-entered into each new record created in the portal so that the newly created record automatically contained the value need to meet that portal's filter requirements so that no newly entered data disappeared due to being excluded by the current portal's filter.
The names of the individual S/N fields are entered by the technician filling out the form. I intended to have that value for them to fill out as the serial numbers are frequently determined by the part being tested and is not usually sequential. Also in cases where a sample uses more than the 17 data points allowed in the portal column, they can just enter the same serial number in the next column or leave it blank.
The Get (ActiveFieldTableName) is what I was originally looking for, it gives me what I expected. I like the sound of your other approach, have to read through it again to make sure I understand how it sets the Data::serial number field. It would need to be entered each time a new record is created in a portal and the $$SerialNumb would have to change for each of the portals.
Yea!!!, that seems to work. I defined Data::samplenum to be autoentered calculated value of $$SN. The made a script called get SN that sets $$SN to Get (ActiveFieldTableName ). I set the first field in each portal row to run that script on Object Enter. I changed one of the fields in the portal row to be samplenum to see if it was working and it did. Then changed the field back to prove that it doesn't need to be on the layout and it still works.
I imagine the same script will work for all of the other forms as well, since it is actually grabbing the name of the current portal and placing it into the samplenum field of the current data record.
Thank you Phil. That saves me a hundred scripts or so.
Now to figure out how to import the applicable data records into a report file and get the report file to generate the right number of records for each form.......
I would use an OnObjectEnter trigger on the portal, that way the variable is updated no matter which field in the portal row is entered.
Thanks Phil, good suggestion - implemented.
This will get me to the point of being able to collect all of the data. It will be collected by many different technicians, mostly on Ipads and go into a central, hosted Data file. Now to work on how to get it out and into reports.
The report is a separate FM file for each job. I am picturing it as having a Main table for the cover and narrative portion, several form tables, a Data table (related records imported from the main Data file), and a photograph table. I am building on the idea that when the report is finished you can run a script that will step through the layouts sequentially, printing all records, so that forms without data do not print and as many pages as necessary print for those that do have data.
I see 2 options. #1 is to just have the report file go to the hosted Data file and print the forms from there. this has a couple of disadvantages - the data won't be stored with the job file and the main Data file will get huge if we are not able to clean out the old jobs once in a while. We keep records for at least 10 years and have 400-700 jobs per month.
#2 is to import the related records from the main Data file into the report's Data table. The issue with this is how to have the right number of records for each of the forms to display/print the data correctly. I am thinking there should be a way to script this. Each data record has a TestID field which is based on which form it goes with and which page. Values would be something like EV1, EV2, XR1, BP1, BP2, BP3
Is there a way to look through the data records and have it create 2 EV forms, 1 XR form, 3 BP forms and no records in the other form tables (based on the above example) and insert the TestID value into that forms TestID field. i.e. the first record in the EV table would have EV:TestID set to EV1 and the second record to EV2.
Just for point of reference, we keep all invoices in a combined file indefinitely and generate over 500 invoices a day, 6 days a week. that file is truly large (over 4 GB) and the line items table has more than a million records.
Thus, you might find you don't need to keep each job in a separate file, which makes this process much more difficult to manager effectively.
The main issue in ending up with all the data in the final report file is having that file complete with all of the data so that it could be accessed out to 10 years if something were to happen to the main Data file. Also the higher ups lack of trust in the security of having everything stored in one central file, indefinitely. As we do it now, all of the forms are printed out, filled in by hand then scanned in to create the PDFs and saved with all of the photos and other raw data in a "job folder". As the jobs are completed the job folder is moved onto an Archive drive, periodically the archive drive is backed up onto DVD (at least 2 copies stored in different locations). So it is better for "piece of mind" aspect to have the final job folder able to stand alone. Not trying to argue against that method, just trying to explain my circumstances here.
keeping the data all in a central file is not a security risk. What you do is make numerous back up copies of that one unified file and store at least one current copy off site. This is SOP for most DB administrators and isn't all that different from what you are doing now, you just do that with the unified file instead of the individual files.
We do run backups like that with the hosted files now. Hourly backups to a local firewire drive and daily to an off-site backup. The reason for the individual report files is that we want to keep each job "encapsulated" in its own folder with the photos, data, other documents. These folders are on the main server when the job is active, then moves off to an archive drive and DVDs when completed. The bosses want to be able to get the DVD from X years ago, find the job folder and be able to open everything and have it all there. While all the data and text portions take up very little room, the photos in the report can be as many as a couple hundred. Storing as reference keeps the filmaker file size down but we then need to maintain the relative file paths - one of the reasons for the "job folder". The job folders usually end up being from 100 mB to several gB depending on how many photos we take and the other supporting documents, so they need to be moved off the main server to make room for the new jobs.
I agree that it will probably not be a big issue in having all the data remain in the hosted/unified Data file, but the records are only used once for that particular job, not like a line item that could be referenced many times. So the occasional cleaning out of that file would be more of a clutter issue than a memory/speed issue.