Try using local variables. The script should look something like this:
Set Variable [$Contact_ID; Value: Contacts::Contact_ID]
Set Variable [$Name; Value: Contacts::Name]
Go to Layout [Payments]
Set Field [Payments::Contact_ID ; $Contact_ID]
Set Field [Payments::Name ; $Name]
The script that Nick posted will work, but I question three things. One, why are you in a new popup window? Why not just enter payments in a portal on the contacts form?
Second, why are you bringing the Contacts Name into the Payment table? All you need is the foreign Contact key, then thru a relationship from Payment to Contact you can get the name.
And finally, why is the Payments::Contact_id formatted with a drop down list? Changing the Contact on the payment could leave you open to a loss of data integrity. Btw, drop down lists always show the first value, unlike popup menus which are capable of storing the first value (the ID) and displaying the second (a text field).
PS: Alright, another comment, remember popup windows need to be modal. That is, if you decide this is how you want the new payment interface to work, then you need a Pause after the Set Field (Payments:Contact_ID; $Contact_ID) step (you don't need the set field for name). Then, the popup needs two buttons, an OK and a Cancel. OK should be set to Resume script (add a Close Window after the Pause) and Cancel should delete the payment record and then Close Window (button set to Exit script).
Try the payment portal interface.
Hi Nick and Barbara. Thanks for the input. I tried Nick's script and it still didn't work. I'm probably making a simple mistake because I have been looking at this database far too long. Luckily this is not a fatal problem, and is only meant to save the user one step.
Regarding Barbara's questions: the short answer to why I have set things up this way is that I want the user to be able to enter a new payment (or appointment, which is set up the same way) in a new pop-up window from anywhere in the database, not just from the customer record. The primary feature of the database is an appointment calendar, and the user needs to be able to enter new appointments, customers or payments directly from that screen. The pop-up list of alphabetical customer names allows them to select the customer the payment or appointment is for, without navigating to the customer record first. Also, the payment and appointment portals in the customer record do not include all the fields required for entry, so the user wold need to open up those layouts to complete the entry. I am trying to save the user as many steps as possible, and it's all working great except for this one step which continues to elude me.
It would be helpful to hear what didn't work. Nick's script illustrates a standard method of grabbing a key into a variable and then inserting that key as a foreign key in a new table. What didn't work? Did the variable populate with the ContactID? Of course, this method will only work if the layout that you are on when you start the script is based on the Contact table. You mention both a drop down list and a popup list. Which is it? btw, there is no such thing as a popup list, it's a popup menu and has completely different behavior from a drop down list. You say it is a pop-up list of alpha customer names. Yikes. I hope that you mean it's a popup menu with a value list of Customer (Contact) IDs, showing the second value, Contact Full Name.
You didn't address my comment about popup window modality. Do you have that technique under control? If you don't, you risk a user clicking on a background window without dismissing the popup first.
What didn't work: When the layout opens, the contact_id field is active/highlighted, but no value is selected from the drop-down list (yes, it is a drop-down list). This is the same thing that happened with the other scripts I tried. One thing to note is that Nick's script did not include a new record request, which is needed to add the payment. Just to see what would happen, I deleted this step from my script, and it returned a random payment that had already been entered for the current contact, including the contact name in the correct field. When I re-added the new record request, nothing happened again, except a blank new payment record with the id_contact field active and empty (I added it after "go to layout" before "set field"). I also did not include the set variable and set field steps for the customer name, because I have that field set to auto-enter when the contact id is selected.
Regarding the pop-up windows, I understand your concern about this. Currently these layouts have two buttons: done and cancel, which both close the window. However, the user is able to click off the window before they have clicked either of these buttons. I have not seen this as a problem because the window will stay open until one of these buttons is clicked or the window is manually closed, but I can see how it could get lost in the background if the user gets busy. I'll consider adding this extra step.
Good catch on Nick's script, of course you need the New Record step.
I think the problem is with the ContactID field or the value list that you have attached to it. Just to make sure, the Contact ID is a field in the Payments table. In my solutions, I would name it _kF_ContactID to indicate that it is a foreign key, because the primary key in the Payments table is PaymentID (__kP_PaymentID in my nomenclature).
So you should be setting the foreign ContactID in Payments to the $variable, $ContactID. Remove the dropdown list from this field, and leave it a plain Edit box. This field should contain ContactIDs (specifically, NOT contact names). Correct?
As I said before, you don't need a Contact Name in Payments. That is obtained by looking back to Contacts thru a relationship Payment::ContactID to Contacts::ContactID.
Why do your two buttons do the same thing? I would expect a user to think that Cancel would differ from Done.