Announcement

**Isomorphic** · 15 Sep 2023, 16:02

Hi Gene,

Is this meant to be standalone code to reproduce a problem? You mention a DataSource, but you didn't provide one, and you mention that the initial state of the data seems to be involved, but you didn't provide data.

Also, it's not clear why you would call setEditValue() in the midst of a change() event. That's not a valid time to call setEditValue(), and it seems like it might be intended to establish an initial value, which is more something to do in rowEditorEnter or by passing values to startEditingNew().

Overall though, aside from these usage issues, what appears to be happening is pretty simple: the field is declared as type:"number" and the actual field value looks like it may be a String (it lacks normal Number APIs). But without seeing the data, we can't confirm that.

**genev** · 15 Sep 2023, 18:34

Thank you for getting back to me.

I'm simply using setData([]) to populate the table. This particular value is always a decimal number. If I change back-end implementation to send integers, it works. It also works for .0 decimals but any digit other than 0 after the decimal point now causes this issue.

I tried doing parseFloat() as the first line and that didn't help.

Commenting out the entire change() method doesn't help.

Commenting out setEditValue() call doesn't help either. The error is exactly the same. //epSumDB.setEditValue(rowNum,1.0,parseFloat(value));
In fact, even if I leave the changed method body completely empty, I'm still getting this error.

This code still fails:

Code:

,getEditorProperties:function(editField, editedRecord, rowNum){
        console.log("getEditorProperties() editField.name="+editField.name+"; rowNum="+rowNum);
        if(editField.name=="lngE"){
            var item = { editorType:"SpinnerItem", type:"float", minValue:0.0, maxValue:360.0, step:1.0, //it fails without type:"float" and with or without specifying min/max Values and step as decimals or integers.
                changed : function(form, item, value){

                }
            };
            return item;
        }
        return null;
    }

The field declaration as "number" was just my attempt to workaround the problem. Originally, I didn't have any type declaration at all. I tried "number" and "float" and that didn't help. Similarly, I didn't use the type:"float" declaration for the SpinnerItem originally, but it fails with and without it.

{name:"lngE", title:"Change Value", width:64, showHover:true, hoverHTML:"return 'Change value'"}, //that was the original field declaration that worked in 11.1. It doesn't in 13.0.

And the main issue is that the original code used to work in 11.1 Pro, I didn't change anything on the back or front end, I simply upgraded to 13.0 Pro and it stopped working.

Thanks,
gene

**Isomorphic** · 15 Sep 2023, 18:49

Hi Gene, if you can enhance your test case to show some sample data that recreates the problem, and the invalid change() handler is also removed, we can take a look.

Just a note that the fact that something worked in a previous version does not mean that there is a framework bug. Invalid usage (that is, code that depends on things that aren’t in the documentation) is still invalid usage, even if it happened to work anyway!

But if this is a framework bug, and you can show that, then we will very much want to fix it!

Announcement

13.0 regression: SpinnerItem Custom Editor fails when dealing with float numbers

Comment

Comment

Comment