setValueFormatter on FloatItem and StaticTextItem does not behave as expected

[petercipov]

Hello,

I have following simple code

FloatItem i = new FloatItem();
i.setFormatOnBlur(true);
i..setValueFormatter(new FormItemValueFormatter() {
@Override
public String formatValue(Object value, Record record, DynamicForm form, FormItem item) {
//do magic formatting
}
});

and I encounter strange behaviour that field is updated to proper value that I create in handler, but just for a while. Callback FormItemValueFormatter is called in onblur event - OK
but value is than quickly changed to other value with editorexit event when mapValueToDisplay of FloatItem is called - NOT OK.
This one does not respect value I have created. And it uses internal formatter from this.formatter property or some default from this._simpleType that actually breaks formatting (I have checked sources you provide).

Maybe I have miss-understood the api but I expect that value provided in setValueFormatter is used for final display. In my case it is not. this._simpleType is used instead and formats value to something else.

Workaround would be to extend FloatItem and override mapDisplayToValue. but I do not want to do so until it is totally necessary.

So I am kindly asking for clarification.

Thanks in advance

smartclient version v11.0p_2017-01-21
browsers: all

[Isomorphic]

We're not seeing this against latest 6.0 - we added a format to your sample code and put the item in a DynamicForm, and it works as expected.

        FloatItem i = new FloatItem();
        i.setFormatOnBlur(true);
        i.setValueFormatter(new FormItemValueFormatter() {                    
           @Override
           public String formatValue(Object value, Record record, DynamicForm form, FormItem item) {
               //do magic formatting
               if (value == null) return "";
               return "isc:" + value.toString() + ":isc";
           }
        });
        
        DynamicForm df = new DynamicForm();
        df.setFields(i);
        df.draw();

Try this code against the latest build from smartclient.com/builds - if it works, you must have other settings, and we'll need to see them.

If not, which OS / browser versions are you using?

[Isomorphic]

Actually, what *is* your magical format? :)

It's possible that you're assembling some other valid float format which is then being incorrectly re-parsed.

[petercipov]

I am sorry not to respond immediately, I have to setup email notifications properly, my bad ;-/

Here is a code from FloatItem.js

handleEditorExit : function () {
this.Super("handleEditorExit", arguments);

this._inEditorMode = false;

//////// ---- Intersting part here ------
var value = this.getValue(),
displayValue = this.mapValueToDisplay(value);
this.setElementValue(displayValue, value);
},

Last time I have forgotten to add also this handler

i.addEditorExitHandler(new EditorExitHandler() {
@Override
public void onEditorExit(EditorExitEvent event) {
// magic here
}
});

This function is called every time item exits editor. in javascript code (marked above) function this.mapValueToDisplay is explicitly called and rewrite my formatting. If I would use setFormat instead of custom formatter it would work. mapValueToDisplaySupports string formatter but I cant in my case :(. So value is correct for microsecond and then rewritten.


Hopefully this makes case more clear.

[Isomorphic]

As we already noted, we don't see the issue you're experiencing in our tests.

Instead of showing code-snippets that hint at magical missing code, please just show the code as we asked - we can't fix an issue if we can't reproduce it.

[petercipov]

In the end it was mistake on my side. I have tracked it as you have said created simple app with floatItem that worked and it turned out that it was our code that does it. Nightmare to debug and track.

that formatting code is very complex. lots of if statements ... part of legacy ... ;-) and on one place it added

item.setType(FieldType.LOCALEFLOAT.getValue()); that made the difference ....

Thanks for support.



Lesson of the day .... Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it? (Brian Kernighan)