Issues with number formatting (decimalPrecision/decimalPad) after update

[eric.maziade.afsi]

We're looking at updating SC from SmartClient_v110p_2016-07-26_Pro to the latest.

All SimpleType-based fields dealing with numbers started failing.

I've tracked the issue to the number formatting in FloatItem.

* The decimalPad and decimalPrecsion were undefined (my understanding of the documentation is that the default value should have been 'null')
* If decimalPrecision is not set, the formatting routine will return undefined (in our current version the number formatting was not yet implemented in SC and the unmodified value was returned)

Regards,
--
Eric

[Isomorphic]

Is this a bug report? If so, what is the problem - please be more specific than "failing".

Also, how can it be reproduced? You seem like you may be talking about a problem that happens only when you have your own formatters installed, if so, of course we'll need to see those.

Also, by "the latest" do you mean 11.0p or 11.1d?

[eric.maziade.afsi]

With v11.0p_2017-02-09/Pro Deployment, the parseInput from the SimpleType derivate will receive "undefined" for the value, if the decimalPrecision was not defined.
Under v11.0p_2016-08-13/Pro Deployment, the value comes in unmodified (as expected).

I've written the following example to reproduce the issue with as little noise as possible.

This code will run fine with the 2016-08-13 version, but will trigger the alert in the 2017-02-09 version.

This would result in either the code breaking because it is expecting value... or the value going empty when you start to edit it.

        
        var SimpleTypeDerivate = isc.defineClass('SimpleTypeDerivate', 'SimpleType');

        SimpleTypeDerivate.addProperties({

            name : 'simpleTypeDerivate',
            inheritsFrom : 'float',

            editorProperties : { length : 10 },
            
            parseInput : function(value, field) {

                if (value === undefined)
                    alert("`value` come up as undefined with the new version (v11.0p_2017-02-09/Pro Deployment)...\nBut comes proper with our current version (v11.0p_2016-08-13/Pro Deployment)");

                // Some transformation would occur...

                var parsedValue = value ? value.replace(/%$/gm,'') : '';
                return parsedValue;
            }
        });

        SimpleTypeDerivate.create();
        
        var grid = isc.ListGrid.create({
            canEdit: true,
            dataSource : DataSource.create ({
                ID : 'myDataSource',
                clientOnly : true,
                testData :
                [
                    { 'test': 1.25 },
                    { 'test': 3.1245 },
                    { 'test': 5.67 }
                ],
                fields : 
                [
                    { name : 'test', type : 'simpleTypeDerivate'},
                ]
            }), 
            data : [
                    { 'test': 1.25 },
                    { 'test': 3.1245 },
                    { 'test': 5.67 }
                ],
        });
        
        isc.DynamicForm.create ({
            members: [ grid ]
        }).show();

[Isomorphic]

Apologies for the delay on this one - you just need to set enforceLength: false on your float-based items - see the doc for that attribute.

Note that there are numerous issues with this sample code that you may want to address if your real code looks like that - you should just be creating an instance of SimpleType with the attributes you want to install, rather than subclassing SimpleType - also, your DS should have a primaryKey: true field if it's allowing editing - and if it *is* allowing editing, you want to set autoFetchData:true and get rid of the 'data' array you apply to the grid directly, since it will come from the dataSource.

[Isomorphic]

Actually, although our previous advice does address your issue, there was indeed a bug here, in the circumstances you mentioned.

We've fixed it for tomorrow's builds.

[eric.maziade.afsi]

Actually, although our previous advice does address your issue, there was indeed a bug here, in the circumstances you mentioned.

We've fixed it for tomorrow's builds.

Great - thanks !