record or records ?

Viewing 11 reply threads
  • Author
  • October 24, 2019 at 12:39 PM #37336


    I am trying to figure out to limit a script execution for a list of records or for a currently open recordset.

    Behavior of the script below:
    When I open a table it works as expected.
    By opening a recordset of this table it works as expected as well.
    But when I go back to the list of recordsets
    the scripts assumes a recordset is still open.

    My script may be wrong, so my main question is how to detect if there‘s a list (recordsets) or a single recordset opened.

    Use case:
    I do have scripts accessing ALL recordsets
    and I do have scripts accessing only fields of the current opened recordset.
    I‘d like to prevent the execution in the wrong view.

    function check() {
       try {
          var res=record.getFieldValue('fld-76b2c64fccc34c20b62b7d485f5bfa28');
       } catch (err) {
          return 2;
    function myFunction() {
       Utils.alertWithMessage('Hello', 'Here I am !');
    var tmp=check();
    if (tmp != 2){
    } else {
       Utils.alertWithMessage('Notice', 'A recordset must be opened');
    October 24, 2019 at 10:00 PM #37344

    Sam Moffatt

    Do you mind sharing a sample form demonstrating the problem? I’m not sure I quite follow.

    One though could be changing from var to let. var puts a variable in global scope whilst let isolates it to block scope. What is block scope? Any code at the same or lower level of brace. The Mozilla JavaScript reference on let has some details about use cases.

    There is also another caveat that sometimes Tap Forms will reuse a Javascript context.

    October 29, 2019 at 11:19 AM #37535


    Let did not solve it.

    How to explain ?
    I do have a form with a lot of repeating fields.



    A script will look for the next empty date,
    will set a date, name and task.

    This script is executed when a recordset is open.

    Another script will be executed as „clean up“,
    remove expired recordsets by date.

    My goal is to prevent the execution of a script in the wrong view.

    There are differences between a loop over all recordsets
    or just the current visible record.

    October 29, 2019 at 6:22 PM #37556

    Sam Moffatt

    I’m not sure I understand what you mean so let me see if I can meet you half way to figure this out.

    My guess is you have either a form script you run manually or a field script somewhere that is connected to a field in your parent form. I’m also guessing you have another field script that is connected to a field either in the same form or maybe a child form.

    When your first script runs (either manually as a form script or in response to a field it watches changing), you end up in a situation where the other script is running. Form scripts are fun in that they can execute without record being set which can lead to interesting situations if you don’t expect that, that could be the first source of your problem.

    If your first script does a setFieldValue on a field that the second script is watching, it will trigger the second script to run. There is a third variable for setFieldValue which you can set to false or zero that will prevent scripts from running when the value of that field changes. The second script I believe is executed in the same Javascript context as the first which means variables can be shared between them. Variables like record is a special variable and I’m not sure what it would be in the context of a child record. However for scripts within the same form, in my experience they quite often share the same Javascript context.

    Because they share the same Javascript context, any variables you assign in the first script will be available to the second script and any variable that was defined in the first script you alter in the second script will change the value in the first script.

    A simple example could be that you use records in your first script and then also use records in the second script. If that second script is triggered based on a setFieldValue in the first script, then the next line after the setFieldValue in the first script will have the value of records from the second script. If you’re dealing with loops this can result in all sorts of odd behaviours with records you don’t expect showing up.

    This is really confusingly written however unfortunately I don’t know how to simply explain it. I hope this makes sense and maybe is applicable for your use case. Let us know if it does or doesn’t help you so we can figure out the path forward :)

    October 30, 2019 at 8:17 AM #37570


    Really confusing, but thanks so far.

    I do not have a script field,
    but scripts to be executed manually.

    I thought there‘s s easy way to detect
    if I‘m in „listview“ or in „record view“.

    Isn’t this a bug ?
    Executing this script in „Listview“:

    function Test2() {
    return res;

    Will cause this error:

    Test2: TypeError: undefined is not an object (evaluating ‘record.getFieldValue’), column:12, line:3

    Opening a record and go back to the listview
    will then show the value of the last opened record,
    which is closed…
    Look like this happens only when a filter is active.

    October 30, 2019 at 9:21 AM #37571

    Daniel Leu

    Are you on a desktop or mobile device?

    October 30, 2019 at 10:44 AM #37573


    iPhone 8 Plus only.

    October 30, 2019 at 11:58 AM #37577

    Daniel Leu

    Oh… I’m mainly on the desktop. Maybe adding a check if record is undefined could be used to avoid fetching a value of an undefined record.

    I have several scripts that operate on the current record or on all records. I use the prompter to select the desired operation.

    October 30, 2019 at 12:32 PM #37579


    The issue is, record is undefined as long as I stay in the list of all records.
    Once opened a recordset and going back to the list it‘s no longer undefined.

    In my point of view this is a bug.

    October 30, 2019 at 2:52 PM #37583

    Daniel Leu

    To me, it kind of makes sense that record is undefined in the list view since no record is active. To which entry should record point to?

    I would not expect that record is defined when going back from record view to list view. That seems to be a strange behavior.

    October 30, 2019 at 10:48 PM #37596

    Sam Moffatt

    Yah, if you’re in the list view then record is empty because you don’t have a record selected. On the desktop this is less of an issue because it’s very hard to never have a record selected but on iOS if you’re inside a pure list view record is blank. I’ve been caught by that before on iOS by running scripts from a list and getting a pop up reminding me I need to be inside a record.

    October 31, 2019 at 12:54 AM #37600


    @Daniel: I would not expect it as well, but it is the case
    Just tested in a testform again:

    function Test2() {
    return res;

    This script will detect res as undefined in a listview, what is normal.
    Opening one recordset and going back to the listview the script will show the field value of the last opened record.

    Means, record is not blank once opened a record and switch back to the listview.

    Possible this is only on iOS the case, but for me it’s a bug.

    @Brendan ?

Viewing 11 reply threads

You must be logged in to reply to this topic.