Unable to get value of the property 'getItems': object is null or undefined ISC_Grid

[subashk]

Getting the following JS error on subsequent fetchData() on a ListGrid. It is fine on the first call, but subsequent calls throws this error.

When does this getItems() function is called?

Also this happens only when the ListGrid has some editable columns.

SCRIPT5007: Unable to get value of the property 'getItems': object is null or undefined
ISC_Grids.js?isc_version=v9.0p_2013-11-03.js, line 1264 character 338

In, Chrome it says:

Uncaught TypeError: Cannot read property 'getItems' of null

Smartclient Version - 9.0 Power Edition
Browser - IE 9, Chrome

[Isomorphic]

Take a look at the FAQ for how to gather necessary information when you see a JS error.

[subashk]

Ok, here is the stacktrace. The ListGrid we have has override of canEditCell() and editorExit(), somehow when we filter using filterEditor when the result becomes to 0 from 1 row on filter, it throws this error.

SCRIPT5007: Unable to get value of the property 'getItems': object is null or undefined
ISC_Grids.js?isc_version=v9.0p_2013-11-03.js, line 1264 character 338

> isc_ListGrid__clearingInactiveEditorHTML
isc_GridBody_redraw
isc_c_Canvas_clearRedrawQueue
isc_c_Class_fireCallback
isc_c_Timer__fireTimeout
anonymous

Any help is appreciated...

[Isomorphic]

In the latest code it doesn't look like there's any way for this JS error to happen. You are more than a year and a half behind on patches, so this isn't surprising. You should at the least update to a patched build, better would be to go to 9.1 as well, best would be the upgrade to 10.0.

[subashk]

We tried with 9.1 Power edition too.

The issue is happening even there...

[Isomorphic]

If it's just as old of a build, the answer is the same - get the latest patches.

[subashk]

SmartClient_v91p_2015-06-04_PowerEdition - Is this isn't the latest?

[Isomorphic]

Yes. Save time and effort next time by telling us *first* that you've already tested with the latest patches, and/or with more recent versions.

However, again, from code inspection, this error appears impossible, and it may be triggered by bad usage. You should try to put together code we can run to see the issue.

[subashk]

Trying to provide a sample code replicating the scenario is time-consuming, as there are so many calls involved that affects this.

may be bad usage, but if you can help us providing some lead on where to look and what to do to find the root cause will be helpful.

We are overriding canEditCell() and editorExit() and filterData() on client side, when there is a filter applied and we setData() to empty array somehow the getItems() error is thrown with this callstack

> isc_ListGrid__clearingInactiveEditorHTML
isc_GridBody_redraw
isc_c_Canvas_clearRedrawQueue
isc_c_Class_fireCallback
isc_c_Timer__fireTimeout
anonymous

This happens only if the grid has editable columns, always issue is when the filter returns 1 or 0 rows

[Isomorphic]

That's very little to go on, but what we can tell you is:

1. the error occurs because the ListGrid is trying to clean up an inline editing interface, but the objects that *should* be there if inline editing is active are mysteriously missing. It's as if overrides have been put in place which cause the editing interface to be dismissed, then dismissed again recursively. This might somehow result from something like call to discardEdits() or cancelEditing() that somehow happens in the midst of a redraw (like from canEditCell(), or from getCellCSSText()). Of course a call like that would be quite invalid.

2. it makes no sense to override filterData() and then call setData() with an Array. You should either allow filterData() to work as designed and create a ResultSet, or you should use DataSource.fetchData() to retrieve data, and apply that via setData(). Mixing filterData() and setData() sets the grid up to expect that it will be managing a ResultSet, then swaps in a different kind of dataset midway through.

[subashk]

Update after in depth testing

for(var i=0;i<_6.length;i++){
_6[i].clearAllInactiveEditorContexts()
}}

I have removed all discardEdits() and cancelEditing(), along with narrowing this issue down to doing a fetch call and going from a ListGrid with one row to a ListGrid with zero rows. All other scenarios have been fixed, but this one is not acting like the others like switching from many rows to zero rows, this works fine. I have also put breakpoints into the canEditCell() and getCellCSSText() methods and have found that even though the ListGrid with zero rows returns null from getEditForm(), it still returns 1 from getTotalRows() and the data array from getData() is an empty array. There is something different about switching from a ListGrid with one row to a ListGrid with zero rows. I have also tested out altering your core code and it’s a change that I think should have been there in the first place. The above code is what it is in ‘ISC_Grids.js?isc_version=v9.0p_2013-11-03.js, line 1264 character 338’ simple and direct get the list of items in the edit form to clear. It should have a null check on it in case the code is called and getEditForm() returns null. In the case of a ListGrid that has canEdit: false property or a list grid with zero rows this method always returns null to getEditForm() because there is nothing to edit. So a simple null check would prevent the error that is happening from ever happening. There is no down side to this as well because the point of this else statement is to remove inactive editor contexts, if the edit form is null there is nothing to remove and it can simply move on.
This is what it should be to avoid this and other errors.

else{
var _5=this.getEditForm();
if(_5 != null){
var _6=_5.getItems();
for(var i=0;i<_6.length;i++){
_6[i].clearAllInactiveEditorContexts();
}
}

[Isomorphic]

The editForm referenced in this code should never be null. Adding a null check would be just a hack to cover up the problem, and could cause other problems, so it's definitely not a framework change we want to make.

It's still unclear whether the root cause of this problem is a usage issue or an actual framework bug.

You mention that the ListGrid is in a state that you seem to think is an indication of a problem:

the ListGrid with zero rows returns null from getEditForm(), it still returns 1 from getTotalRows() and the data array from getData() is an empty array

This is a normal circumstance which indicates that a new row was being added by inline editing, and has not been saved. Unsaved rows are stored separately from listGrid.data (which contains only *saved* rows), so it's normal to have an empty dataset and an unsaved row. You should read or re-read the ListGrid Editing overview if it's not clear that this is a normal circumstance.

As far as how you ultimately get the ListGrid into a state where there should be an editForm but isn't, we mentioned this usage problem in your code:

2. it makes no sense to override filterData() and then call setData() with an Array. You should either allow filterData() to work as designed and create a ResultSet, or you should use DataSource.fetchData() to retrieve data, and apply that via setData(). Mixing filterData() and setData() sets the grid up to expect that it will be managing a ResultSet, then swaps in a different kind of dataset midway through.

It does not appear that you've addressed this. It's probably the root cause of your issue.