In the FM 16/17 example App "Expense Report" the Data::EXPENSE ID MATCH FIELD is defined as an calculation:
IsEmpty ( $$CURRENT_EXPENSE_ID ) ; Self ;
What does 'Self" refer to in this context? Get ( RecordID )?
Without looking at the file, $$CURRENT_EXPENSE_ID is a global variable.
For the field in question, its basically saying, if the global field is empty, return what is already in the field, otherwise use the global variable.
I have no idea why the font size changed on my post).
The existing value of Data::EXPENSE ID MATCH FIELD.
Only when empty, a new value ($$_current....) is applied.
Only when new value is not empty, a new value ($$_current....) is applied.
I think now it might be because these "data" records are created in a portal on an 'Expense" record, they automatically get assigned an value as it is a match field. The value is assigned before the calculation is executed, thus function 'Self" is now defined.
SteveMartino wrote: I have no idea why the font size changed on my post).
Did you copy and paste $$CURRENT_EXPENSE_ID by chance?
This is a weird calculation. Is it actually a field of type "calculation" or of text (or number) with an auto-enter calculation?
If this is a calculation field then if stored, it will not update when $$CURRENT_EXPENSE_ID is modified since that is a variable, not a field in the table and you'll never be able to trigger an update since you can't modify a calculation field and get Self to trigger. If unstored, Self() won't resolve to anything and it's just $$CURRENT_EXPENSE_ID all the time.
“Is it actually a field of type "calculation"?”
clearly, it can’t be a calculation field if it uses Self.
It does not appear that any of the previous replies actually opened the "Expense Report" example app!
If you go to define fields
Data::EXPENSE ID MATCH FIELD
is a NUMBER field type, as an Indexed, Auto-enter calculation. The TO (context) is "Data | Expenses" where
Expenses::EXPENSE ID MATCH FIELD = Data | Expenses::EXPENSE ID MATCH FIELD
AND Expenses::TYPE EXPENSES MATCH FIELD = Data | Expenses::Type | MATCH FIELD
The formula is:
If ( IsEmpty ( $$CURRENT_EXPENSE_ID ) ; Self ; $$CURRENT_EXPENSE_ID) // replaces existing value
There are several scripts that 'set' the $$CURRENT_EXPENSE_ID:
iOS: Go to Selected Expense | iOS
iOS: Go to Selected Mileage | iOS
iOS: Add Expense or Mileage | iOS
Web: Go to Selected Expense | Web
Web: Go to Selected Mileage | Web
Web: Add Expense or Mileage | Web
I did not delve deeper to see what triggers any of these scripts or if there were other obscure triggers (besides button calls to the scripts).
Perhaps the others can assist you better, now?
This is a technique used to automatically link new child records to an existing parent without using a “create enabled“ relationship (nearly always via a portal) to do so.
The scripts set the global variable to a specific match field value from the parent record. All subsequent new records in the child table automatically get that value in their match fields.
The use of the If function isn’t really needed as you could just specify the global variable as the calculation and get the same results. I don’t think that you’d even need to select the “do not replace existing value option given that there’s no need to reference anything but the global variable.
(Once again the unprofessional lack of internal documentation in the starter solution‘s has confused a new user. )
DITTO, PLUS ONE, YES!
The starter/example files should have tutorials. The starter/example files should have some explanation of why they are the way they are!
"clearly, it can’t be a calculation field if it uses Self."
I'm not sure what you mean.
A FileMaker calculation field is perfectly happy to accept the Self() function.
From a one minute examination, I'm not 100% sure what the calculation is doing. There is a script that uses that global variable when creating a new record, which is a valid way of setting an ID field, though not my ideal. The Self could be a backup in case a user bypasses the scripted process and duplicates a record, then the ID of the original will be preserved (rather than just null).
Apologies David, I'd swear that the last time I tried self in a calculation field, it didn't work and kicked back with an error when I tried to close the calculation dialog.
Several years ago, I met the person that created/updated one of the starter solution sets, and provided the same feed back. The reason given, which I won't repeat here as this may not be the reason given today, left me scratching my head as it really made no sense. HE wanted to use comments, etc, but was not allowed to do so, making this stranger and stranger....
That would be my guess. I didn't explore if "new record" had an effect (if the scripts did NOT set the variable). TY DavidJondreau
I heard that too. Still there are some strange methods that I'd NEVER use in any solution...
Thanks you folks for thinking this out with me.
I think bervery is on the correct road here. It is not as complicated as I first thought and has to do with that in small screens (IOS), where we tend to avoid portals.
In a parent-child relationship, we can automatically match the child to the parent by automatically populate the child's foreign record id (_kf_parentID) in a portal. We do this by check-marking the "Allow creation of records in this table via this relationship". New child records automatically inherit the _kf_parentID this way. This works great.
When we design for IOS platform we tend to avoid portal and this technique does not work. With IOS we use use one layout for the parent data and another layout the the child data. So we need to assign the child record in an other way.
We can assign a new child's record _kf_parentID by 4 script steps or do it in 3 step by use the odd calculation in the field definition:
IsEmpty ( $$CURRENT_PARENT_ID ) ; Self ;
Set Variable [$$CURRENT_PARENT_ID ; Value: Parent::PrimaryKey ]
Go to Layout ['Child" (child) ; Animation None]
which saves you one step from the way we normally do it:
Set Field [Child::_kf_ParentID ; $$CURRENT_PARENT_ID]
I don't think it is worth it doing it that way.
But what we learn is that in a portal with "Allow creation of records in this table via this relationship" the _kf_ParentID get assigned a value, before the field calculation is is executed. Is there an other case where this knowledge would come in handy?
Nice rational, oak ! You should write some documentation for this starter/sample solution!
I will use scritpts and functions for 'dual-duty' like this, but I will heavily comment them so there is no confusion.
Retrieving data ...