Working with Tables from another Session and with Child Tables on a Form
Assume that you have two forms open, FormA and FormB. It is possible for a script that is attached to a button or event in FormB to manipulate (i.e., enter, edit, delete records etc.) the table or tables that FormA is based on. Generally when a script needs to manipulate a table in the current session, you obtain a reference to the table in the current session using the TABLE.CURRENT() method. For example, the following script, which is attached to a button on a form, enters a record into the table on which the form is based:
tbl = table.current() tbl.enter_begin() tbl.first_name = "Fred" tbl.last_name = "Jones" tbl.enter_end(.T.) parent.resynch() 'resynch the form to display the new record
The following code does the exact same thing using a more cumbersome syntax to refer to the table that the form is based on:
parent:tables:customer.enter_begin() parent:tables:customer.first_name = "Fred" parent:tables:customer.last_name = "Jones" parent:tables:customer.enter_end(.T.)
As the above examples show, you can refer to a table's methods or properties in a form (or browse) using this syntax:
All Field Rules vs Validation Field Rules
In the above example, the alias Parent is used in place of the actual window name. So, for example, if FormA is based on a table called Customer, then the following Xbasic script could be attached to a button on Form B:
:FormA:Tables:Customer.enter_begin() :FormA:Tables:Customer.first_name = "Fred" :FormA:Tables:Customer.last_name = "Jones" :FormA:Tables:Customer.enter_end(.T.)
Contrast the above example, which enters a new record in the Customer table by "working behind the scenes" with the following code which achieves the same thing, but manipulates the form directly.
:FormA.new_record() :FormA:first_name.value = "Fred" :FormA:last_name.value = "Jones" :FormA.commit()
Note that while the above two code fragments both add a new record to the Customer table, there are significant differences. Because the second code fragment directly manipulates the form, it works as though the user himself was typing the data into the new record. This means that all field rules are in effect. So, for example, if the first_name field had a rule that capitalized text, the first_name value would be stored as "FRED". Since the first code fragment works "behind the scenes", only validation field rules are in effect. Capitalization field rules, for example, would be ignored.