OnObjectExit will perform your script every time you exit the field. Just clicking in the field and then clicking somewhere else outside the field will trip your trigger and create a new record as specified in your script.
OnObjectSave, on the other hand, will only be tripped if you change the value of the field. That get's you closer to where you want to go. But you still need to be able to detect when the value of the field was empty before the contents of the field were modified.
Specify Shipline::Container1 as the script trigger's container field and then your script can check to see if Get ( ScriptParameter ) is empty. If it is, the field was empty before the data that tripped the OnObjectSave trigger was entered.
But I would try to use a portal to a different table occurrence of Container with "allow creation" enabled and two portal rows in place of Container 1 and Container 2. That would allow me to create records in Container, linked to ShipLIne without any need for scripts to keep the data "in synch".
I tried to use Get(ScriptParameter), but I pretty sure I am not using it correctly. It works a little better than before; it doesn't create two new records every time I go back to change something, but it still creates a new record in the container table when I modify the field in shipline.
I see an omission in my previous post. I forgot to include: "You need to specify Shipline::Container1 as the expression in the script triggers optional script parameter box."
Did you do that?
I am not sure if I am writing the script correctly. I put Shipline::Container1 in the optional script parameter box, but now it does not create a record in the container table.
It looks like your script IS creating the new record, but I don't see any code to set the match fields to the needed values such that the new record will be linked to any other related records.
If you are also setting up a portal to an occurrence of Container with a relationship such as:
Shipline::pk 6 = Container::fk 6 (but you may need a join table so that container can link to multiple ship line records and then this requires creating an additional record in a join table.)
At the start of the script, you'd need:
Set Variable [$ShipLineID ; value; ShipLine::pk 6 ]
And after the New Record/Request:
Set Field [Container::Fk 6 ; $ShipLineID ]
But as noted, it could be that you need linking record in a join table instead.
I tried linking the two tables together and using set variable and field like you suggested, but it is not creating a new record for container 1.
I am not using portals with portal rows in place of container 1 and 2 because each container will be in its own tab in a different layout. There will be addition and subtraction calculations that works between container 1 and 2. I could not figure how I can get the correct container in the two tabs if I did not make two separate fields for containers. That's why I am trying to use scripts to try to copy over the container name from shipline into the container table.
Add this step just before the New Record/Request step:
Show Custom Dialog [ Get ( ScriptParameter ) ]
Check and see if the dialog appears and what data appears in it.
If the dialog is popping up, the script IS creating a new record but for some reason you are not able to see the new record where you expect it.
The dialog does not pop up.
I deleted Shipline:Container1 in the optional script parameter box and the dialog box came up, but it was blank. Does this mean I wrote something wrong in my script?
Actually, it means that the script is functioning as you have designed it to function. This script is supposed to detect when a value has been entered into a field that was previously blanked. But I must profoundly apologize. It wasn't until I looked again at this script that I realized the problem. This won't detect when a new value has been entered into the field.
You'll need two script triggers. Use the onObjectEnter Script Trigger with the ShipLine::Container1 script parameter to do this:
Set Variable [$$Cont1Old ; value: Get ( ScriptParameter ) ]
Then modify your existing script to use:
If [IsEmpty ( $$Cont1Old ) ]
But you'll also need to clear this global variable each time you change records or this will still not work reliably. The OnRecordLoad trigger can be used to perform a script to clear the variable.
Oh it's okay, I am very thankful for your help.
I tried your suggestions, but a new record is created every time I modify the Shipline::container1.
I am not sure if it is because I am writing the script to clear the global variable incorrectly.
Set Variable [ $$Cont1Old; Value: ""]
That is the correct script step. But disable that script trigger and test.
Does it then seem to work as long as you don't change to a different record?
Then run the scrip to clear the field from the script manager and try on a different record. Does it still work?
The script to create a new record is tripping the OnRecordLoad trigger and thus the variable is being cleared when it shouldn't be.
Try this new script to clear the variable.
If [ Not $$TriggersOff ]
Set Variable [ $$Cont1Old; Value: ""]
Set Variable [ $$Cont2Old; Value: ""]
Then add this step to the very beginning of the first script:
Set Variable [$$TriggersOff ; value: True ]
and this one to the end of it:
Set Variable [$$TriggersOff ; Value: False ]
Sorry, the Set Variable [ $$Cont1Old; Value: ""] works. I was negligent and forgot to put shipline::container1 in the optional script parameter which stopped the scripts from working.
It creates the new record now, but if I modify the field, the value in the container field does not change.
And that is how this is set up to work. IF you want to modify the field's value in the container field--a request that I don't recall was part of your original post, this field shouldn't be in Shiplines at all, you should be modifying the field directly in the related table and an Id field should be used to link ShipLines either to the record or to a join table that links to the record.