Handle new record input in script

[Racer Bob]

Well, I have exhausted the instructional sources I have access to on this. I can't find anyway to prevent a script from executing all script steps before taking any values for the fields in a new record. This is a problem as I want to use some of the new record's fields to add to a matching new related record in a related table portal. First enter main record, then create related record in the portal with some shared information automatically transfered.

Problem is the values are placed into the new related record's fields before the primary record is even filled out. Of course this means blank fields in the new related record.

I have tried using the commit step in different locations in the script but doesn't make any difference. I need to do all this in one step, either all in one script or from another script being activated by the main script.

I tried the pause step after the new record step but that does't help, all it does is stall the script. By the way, the only key that will resume the script is the enter key on the number pad, what is with that ? And how is the use of the enter key affected during a pause if it is also allowed for moving from one field to the next, does this interfer with the pause step's use of the enter key ?

I would love to copy the script into this question but I have yet to find a way to copy from the program onto the clip board. The copy function in the script editor doesn't copy to the clip board. Any suggestions on this ? I can't find anyway to print the scripts either, so I am reduced to hand copying scripts ?

I have to wonder about the lack of information on some really fundamental aspects of this program. I'm I alone in this ?

[Raybaudi]

I can't find anyway to print the scripts either, so I am reduced to hand copying scripts ?

Hi

post your script.

If you don't want to hand copying it, make a DDR and select/copy the script from it !

[Genx]

Or if you can print to pdf... print to pdf, or take a screen shot if it's short enough, or take lots of screen shots and paste them together :

[Raybaudi]

I can't find anyway to print the scripts either...

To print a script, simply open ScriptMaker, select the script to print and...pusch the PRINT button :

[Racer Bob]

Ok, I find a print option on the script list, I was looking for it with the script steps displayed. Seemed more logical to me but what ever works.

Tried printing it to file but no options of what type of file are offered and I can't find any program that can read the resulting file. ah Windows.

Still looking for the original question, I have developed a work around which requires a seperate button to activate an entirely seperate script not called from or listed in the original script. Bit clumsy.

Is this the only way ?

[jamesducker]

So I gather from your description: you want to start on a record in table A, then create related records in table B with some of the information from the "header" record in table A copied in?

You could achieve this using variables; your script could be:

set variable [$headerID ; tableA::UniqueID]

set variable [$date ; tableA::date]

set variable [$time ; tableA::time]

set variable [$place ; tableA::place]

go to layout [table B]

new record/request

set field [tableB::parentHeaderID ; $headerID]

set field [tableB::date ; $date]

set field [tableB::time ; $time]

set field [tableB::place ; $place]

commit records/requests

go to layout [original layout]

You can't short-circuit this by simply changing to layout B and setting tableB fields to tableA fields, because when the script changes to a tableB layout the context in which it is operating has changed. FileMaker (rightly, in my view) does not automatically make any link between tables simply based on what you were doing last.

If the records in table B were ALWAYS generated in this way, it would be sensible to define the table B fields as calculations, ie the definition of 'tableB::date' would be 'headerInTableA::date' (where "headerInTableA" is a relationship defined to match 'parentHeaderID' in table B with 'UniqueID' in table A.

[comment]

I can't find anyway to prevent a script from executing all script steps before taking any values for the fields in a new record.

Why can't your script pause for user input, then check if all required fields are filled and proceed accordingly?

[Racer Bob]

Thanks for your replies. Let me go over some of the details. Both tables are filled in from one layout. Table A is a list view in the body of the layout. Table B is in a related portal in the footer of the layout.

If have tried to use one script to enter first the fields in Table A then try to use the new record values from the table A record for the next new record in Table B. Only one field for Table B needs to be entered by the user.

But if the steps to use the Table A values for Table B fields is included in, or in a seperate script called by the current script, they all will be executed before the actual values have been inputed to the Table A record fields.

This then puts blank or empty values into the new related record from Table B before the values for Table A have even been entered.

Trying to place a PAUSE step anywhere in the script makes no difference. The script will not go to the field inputs until the pause has been cleared and all remaining script steps (and any PERFORM SCRIPT step) have been completed.

Putting a COMMIT RECORD step anywhere in the script, such as after the NEW RECORD REQUEST, makes no difference. Same story, all steps will be executed before user input is started.

I can make all this work fine if I use two unrelated scripts and a button to call the second script but this requires extra action by the user which means more chances for things to go wrong. One script would be better.

What do you think ?

[comment]

Could you explain the purpose behind all this? Table A and Table B is rather confusing. It is also not clear who is filling which values when (user or script). In short, you've lost me.

[Racer Bob]

Let me try again.

Purpose : to keep track of milage on parts in vehicles so thay can be serviced or changed as necessary and to keep a record of all this

Files : File tables MAIN = Vehicle

TABLE A = Parts assigned to a specific vehicle. Handled as List view on layout being limited to just records related to a specified vehicle from MAIN table

TABLE B = Record of actions on each part so will have a history. Handled as Portal in Footer of layout.

Process involves : Entering a new part, replacing or servicing existing parts in TABLE A. Dates and milage are entered into selected fields in the record from TABLE A. This then automatically creates a new record in TABLE B using the just entered values from TABLE A and prompts the user to fill in the last field for the TABLE B record.

All this is to be done by a user who does not know anything about FileMaker, only how to do what allowed by the program. Following prompts and choosing options listed in buttons on the layout.

I can make all this happen but not from one script. Problem once again is I can't find a way to allow filling in the fields for TABLE A before all steps in script have been executed. These steps transfer TABLE A field values to fields in the new record being created in TABLE B. The program insists on executing all steps in the script before actually allowing input to fields for the new record in TABLE A which must proceed the creation of the record in TABLE B.

Sorry, hope this is understandable, don't know how to make it any clearer. It is my understanding that this is the kind of thing the program is supposed to handle, if I have to use seperate layouts for each table then I might just as well use a spread sheet.

[comment]

I am afraid I am still confused. I got this far: Vehicles, Parts, Actions. How are they related? Why should it be necessary to duplicate values already entered in one table into another?

I would suggest you put the layouts and user interface aside for a while, and concentrate on the data structure.

[Racer Bob]

Sorry, clearly I am using the program at a much higher level than some folks. This is what the program is supposed to be about. I can make it all happen, just not a cleanly as I would have hoped for. I'll try the tech folks for FileMaker, they should have a deeper grasp of how the program works.

[comment]

Yes, they should.

[Racer Bob]

Subsequent Investigation Shows the following information which should help anyone else encountering this situation.

When a new record is entered through a script using the NEW RECORD REQUEST, there is no way to keep the script from executing all it's included steps before the program will go to a field and start taking entry of values for that field.

If there are any steps that must not be executed until after the values for the new record fields have been entered, they must not be included in the same script that contains the NEW RECORD REQUEST.

This also applies to a script that is called from within the original script by way of the PERFORM SCRIPT step.

Only after the completion of all the steps in the script which includes the NEW RECORD REQUEST (including scripts called via PERFORM SCRIPT)can guaranteed access be made to the newly entered field values. In essence this means that it requires two separate scripts.