decimalPad and decimalPrecision not working with staticText

[wallytax]

I'm just giving this example to demonstrate what's happening:

    isc.NumberUtil.decimalSymbol = ',';
    isc.NumberUtil.groupingSymbol = '.';

    isc.HLayout.create({
    members: [
        // editorType: 'staticText' without decimalPrecision => OK
        isc.DynamicForm.create({
            fields: [{
                name: 'number',
                defaultValue: 123456.789,
                editorType: 'staticText',
                title: 'Number',
                type: 'localeFloat'
            }],
            width: '*'
        }),

        // decimalPrecision in combination with editorType: 'staticText' => NOT OK
        isc.DynamicForm.create({
            fields: [{
                name: 'number',
                decimalPrecision: 3,
                defaultValue: 123456.789,
                editorType: 'staticText',
                title: 'Number',
                type: 'localeFloat'
            }],
            width: '*'
        }),

        // decimalPrecision in combination with editorProperties { type: 'staticText' } => OK
        isc.DynamicForm.create({
            fields: [{
                name: 'number',
                decimalPrecision: 3,
                defaultValue: 123456.789,
                editorProperties: {
                    type: 'staticText'
                },
                title: 'Number',
                type: 'localeFloat'
            }],
            width: '*'
        })
    ],
    width: '100%'

My intention is to use editorType: 'staticText' and found out that floating numbers are rendered incorrectly. If I replace editorType: 'staticText' with editorProperties: { type: 'staticText' } it works again. Is this a bug?

I also noticed problems with decimals in different locales (mine is Dutch) when editing fields. I have no example of this and I found earlier posts, but using the latest 10.1 version (SmartClient), I'm still seeing those problems.

Any help would be appreciated.

[Isomorphic]

All of your code samples are wrong - correct usage is editorType:"StaticTextItem".

Rather than decimalPrecision we would recommend using dataSourceField.format, which allows you to control more than just precision, and is locale-aware.

Finally, nothing will respond to the current locale unless you actually load the locale file - see the Internationalization overview.

[wallytax]

I've changed my data source fields, so they are still showing correctly, but now using the format property (eg. ",##0.00") and type "float" (instead of "localeFloat"). Is it true that input now is in American style? (using a "." as decimal separator)? If so, is there a way of changing this (easily)?

[Isomorphic]

Yes - go back to using localeFloat. It's not incompatible with using FormatString.

[wallytax]

Will try tomorrow, but I'm pretty sure it has flaws when it comes to validation. Such issues have been described on the forums before.

But anyway, thanks so far.

[wallytax]

If I set the data source field type to "localeFloat", it doesn't complain about a format like "123.4" (which is invalid for my locale, NL, it should have been "123,4".

[Isomorphic]

This is fixed now and will be available for download in nightly builds since Apr 2 (tomorrow).

[wallytax]

Indeed this is fixed, thanks a lot!

However, I'm sorry to have to mention it, there's still a minor, but "annoying" issue. Suppose, if you're like me, used to the Dutch locales, meaning a comma as decimal separator and you accidentally type a number like "1.23". It correctly mentions, this is invalid. But you can't change it to "1,23" because it "jumps" backs to "1.23". A work-around is to change it another value first and then correct it. I believe someone has mentioned this issue before.

[claudiobosticco]

I believe someone has mentioned this issue before.

it was there http://forums.smartclient.com/forum/...765#post207765

I can confirm that the bug shows in
SmartClient Version: v11.0p_2016-04-05/EVAL Development Only (expires 2016.06.04_09.26.33) Licensed to: Isomorphic Software (#ISC_EVAL_NIGHTLY)

[wallytax]

Yep, that's probably it! AFAIK this is not fixed, but that post says something about SC not being sure how to address this. My suggestion would be that an invalid value is internally stored as null and if the new value is correctly it must differ from the invalid value. Maybe that's too short-sighted.

[claudiobosticco]

then I had confirmed the fix (v10.0p_2015-01-19):
http://forums.smartclient.com/forum/...075#post208075

[wallytax]

Without causing confusion: I don't think the issue of changing "1.23" (if that is invalid for example in Dutch) into "1,23" is fixed. In this scenario you need to change it to another value first.

[claudiobosticco]

Without causing confusion: I don't think the issue of changing "1.23" (if that is invalid for example in Dutch) into "1,23" is fixed. In this scenario you need to change it to another value first.

I meant it was resolved in 10.0 (v10.0p_2015-01-19) but there has been a regression in 11.0. I've not tried the latest 10.1.

[Isomorphic]

This is fixed and will be available for download in nightly builds since May 3 (today).

[claudiobosticco]

I meant it was resolved in 10.0 (v10.0p_2015-01-19) but there has been a regression in 11.0. I've not tried the latest 10.1.

SmartClient Version: v11.0p_2016-05-03/EVAL Development Only (expires 2016.07.03_03.32.42) Licensed to: Isomorphic Software (#ISC_EVAL_NIGHTLY)

this works for me