Announcement

**Isomorphic** · 22 Feb 2023, 13:59

From the stack trace, this looks like an "orphaned" FormItem, as in, it doesn't have a form anymore, however, that's odd, as it seems like the form is still holding onto the item.

What this looks like is something like:

1. destroy()ing the form right after asking it to save while the save is still in process (invalid)

2. calling setItems on a form mid-save (also invalid)

3. re-using a formItem definition that was previously provided to one form in a new form (also invalid)

4. directly assigning to formItem.form (also invalid)

If none of those things are being done, let us know.

Note you can use "CODE" tags and it will keep the spacing in your code so it's easier to read.

**jaliaSC** · 23 Feb 2023, 03:06

Hi, none of those things are being done

here's the code from my previous post with the code tags applied

Code:

 
save = function () {
  isc.RPCManager.startQueue();

       dfDetails.saveData(function (dsResponse, dsData, dsRequest) {   // dynamic form save request
             if (dsResponse.status != DSResponse.STATUS_SUCCESS) {
                    isc.warn("Form save error");
              }
       });

   lgdDetailsTable.saveAllEdits();                         //list grid save request                                           
   isc.RPCManager.sendQueue(callback);
}

callback = function (responses) {
                           let lvarErrorExistsFlag = false;
                           let lvarRegisterSubmitResponse;

                           for (let i = 0; i < responses.length; i++) {

                                  lvarRegisterSubmitResponse = responses[i];

                                  if (lvarRegisterSubmitResponse.status != DSResponse.STATUS_SUCCESS) {
                                             lvarErrorExistsFlag = true;
                                 }
                            }

                           if (lvarErrorExistsFlag == false) {
                                  winDetails.closeClick();
                                  isc.say("Saved");
                            }
                     }

*13:01:13.197:XRP3:WARN:Log:TypeError: Cannot read properties of null (reading 'linearMode')
Stack from error.stack:
FormItem.__mayShowHintInField(<no args: exited>) on [TextItem ID:isc_TextItem_0 name:status_cd] @ ISC_Forms.js:1413:211
TextItem._mayShowHintInField(<no args: exited>) on [TextItem ID:isc_TextItem_0 name:status_cd] @ ISC_Forms.js:2110:1238
FormItem._getShowHintInField(<no args: exited>) on [TextItem ID:isc_TextItem_0 name:status_cd] @ ISC_Forms.js:1413:384
TextItem._showValue(<no args: exited>) on [TextItem ID:isc_TextItem_0 name:status_cd] @ ISC_Forms.js:2195:101
FormItem.setValue(<no args: exited>) on [TextItem ID:isc_TextItem_0 name:status_cd] @ ISC_Forms.js:1315:28
[c]Class.invokeSuper(<no args: exited>) on [TextItem ID:isc_TextItem_0 name:status_cd] @ ISC_Core.js:308:162
TextItem.setValue(<no args: exited>) on [TextItem ID:isc_TextItem_0 name:status_cd] @ ISC_Forms.js:2194:9
DynamicForm.setItemValues(<no args: exited>) on [DynamicForm ID:dfChangeCompanyDetails] @ ISC_Forms.js:614:236
DynamicForm.setValues(<no args: exited>) on [DynamicForm ID:dfChangeCompanyDetails] @ ISC_Forms.js:492:22
Canvas.dbcDataSourceDataChanged(<no args: exited>) on [DynamicForm ID:dfChangeCompanyDetails] @ ISC_Core.js:4696:335
_3.eval(<no args: exited>) on [DataSource ID:company] @ [no file]:4:10
_3.thunk(<no args: exited>) on [DynamicForm ID:dfChangeCompanyDetails] @ ISC_Core.js:356:28
_3.observation(<no args: exited>) on [DataSource ID:company] @ ISC_Core.js:352:394
DataSource.updateCaches(<no args: exited>) on [DataSource ID:company] @ ISC_DataBinding.js:404:6
[c]DataSource.handleUpdate(<no args: exited>) on [Class DataSource] @ ISC_DataBinding.js:255:163
DataSource.fireResponseCallbacks(<no args: exited>) on [DataSource ID:company] @ ISC_DataBinding.js:603:192
DataSource._completeResponseProcessing(<no args: exited>) on [DataSource ID:company] @ ISC_DataBinding.js:599:6
DataSource._handleSCServerReply(<no args: exited>) on [DataSource ID:company] @ ISC_DataBinding.js:2627:6
[c]Class.fireCallback(_1=>Obj, _2=>"rpcResponse,data,rpcRequest", _3=>Array[3], _4=>[RPCManager ID:builtinApplication], _5=>undef) on [Class RPCManager] @ ISC_Core.js:320:104
Class.fireCallback(_1=>Obj, _2=>"rpcResponse,data,rpcRequest", _3=>Array[3], _4=>undef) on [RPCManager ID:builtinApplication] @ ISC_Core.js:395:302
[c]RPCManager.fireReplyCallback(_1=>Obj, _2=>Obj, _3=>Obj, _4=>Array[1]) on [Class RPCManager] @ ISC_DataBinding.js:1549:344
[c]RPCManager.fireReplyCallbacks(_1=>Obj, _2=>Obj) on [Class RPCManager] @ ISC_DataBinding.js:1551:120
[c]RPCManager.performOperationReply(_1=>Obj, _2=>Obj) on [Class RPCManager] @ ISC_DataBinding.js:1547:13
RPCManager._performTransactionReply(_1=>11) on [Class RPCManager] @ ISC_DataBinding.js:1537:6
[c]RPCManager.performTransactionReply(_1=>11, _2=>"//isc_RPCResponseStart-->[{affectedRows:..."[10662], _3=>undef) on [Class RPCManager] @ ISC_DataBinding.js:1497:20
null.eval(transactionNum=>11, results=>[object XMLHttpRequest], wd=>undef) @ [no file]:3:16
[c]Class.fireCallback(<no args: recursion>) on [Class Comm] @ ISC_Core.js:320:104
[c]Comm.performXmlTransactionReply(_1=>11, _2=>[object XMLHttpRequest]) on [Class Comm] @ ISC_Core.js:2098:27
null.eval(xmlHttpRequest=>[object XMLHttpRequest]) @ [no file]:3:10
[c]Class.fireCallback(<no args: recursion>) on [Class Class] @ ISC_Core.js:320:104
Comm._fireXMLCallback(_1=>[object XMLHttpRequest], _2=>"isc.Comm.performXmlTransactionReply(11, ..."[55], _3=>undef) on [Class Comm] @ ISC_Core.js:2077:440
XMLHttpRequest._15() @ ISC_Core.js:2085:367

**Isomorphic** · 23 Feb 2023, 15:40

You are calling closeClick() - depending on configuration, this may mean that the Window (and all of its contents) is being destroy()d, in which case, you would indeed be violating the first rule we mentioned (#1 above), which still seems the most likely reason for this error.

You can check whether destroy()s are actually happening in a number of ways:

1) watching the "destroys" count in the Developer Console

2) enabling the "destroy" log category

3) using browser developer tools to stop on this error and checking whether formItem.destroyed is true

**jaliaSC** · 27 Feb 2023, 00:30

Hi, i call closeClick() in the isc.RPCManager.sendQueue callback function which is invoked after the form and list grid are saved. Destroy()s are not happening while saving is in process

I don't think calling closeClick() is the problem because it does save the data when I call the save function for the first time,which saves the data on the window and close the window, then if I reopen the window for further editing and try to save, the error is thrown

**Isomorphic** · 28 Feb 2023, 02:36

The main question is how the form item becomes "orphaned" on the second save - where by "orphaned" we mean that "this.form", as executed by the FormItem, is null - that's the cause of the JS error. We've outlined the possible reasons that we can see for that to happen above; each of those is a usage error with respect to the docs.

If none of those ring a bell, you could watch for this.form property to change; this can be done by using Object.defineProperties() to install a setter method. Either Google or AI (like ChatGPT) can explain the approach if you're up for this level of debugging.

We've also added a null check for this.form here, which allows the code to proceed past this point. This null check had been added to the upcoming 13.1 release already, but it was for a use case involving repeated destruction of form elements involved in inline editing in grids with an enormous number of columns. We don't know whether this will allow your use case to complete as expect because we can't see any reason you'd hit this same situation.

Really, the fact that you're running into the same situation is highly suggestive of a deeper, underlying problem. So, we'd strongly suggest doing at least the next level of diagnostics suggested.

Otherwise, even with the new build with a null check, you might have a "fix" that just leads to an even more bizarre and difficult problem later, because the underlying problem may be application code that is relying on undocumented behavior in a subtle way. Better to figure out what's going on now, or at least take a shot at it!

Another approach is simply to try to reproduce the same error using a simple sample that we can run. But just to note: we already tried that, and couldn't immediately reproduce the issue, at least not with simple forms, windows and a save operation analogous to what you have described.

**jaliaSC** · 28 Feb 2023, 05:39

I fixed the issue by checking if the window that has the form and list grid exists, then i show the window if it exist or create the window if it does not. Seems like the problem was component Id collision. Do you think this fix might cause other problems later?

**Isomorphic** · 28 Feb 2023, 16:30

If you create a component with the same ID as an existing component, it destroy()s the existing component and WARNs loudly in the logs that this has happened.

So this looks like you were, in fact, destroying the original window & form (our first guess)? It's not clear why you said no destroys were happening...

Also we're guessing that you were doing #3 above (re-using FormItem config in multiple forms), which would also cause this error.

Regardless, it's fine to instead re-use the original window. That would be in fact the more normal thing to do, and is somewhat faster.

The only reason to destroy and re-create the Window every time would be if the Window was so different each time that it's simpler to just create a new one rather than call all the necessary setters to reconfigure the existing Window.

Announcement

Calling isc.RPCManager.sendQueue twice throws uncaught type error

Comment

Comment

Comment

Comment

Comment

Comment

Comment