I'll second this one.

fillData should use unformat to get the data, and the custom element should take /that/ string as its input when filling in the value on the edit form.

Mark

So it looks like the custom element has changed since the documentation was written:

custom_element.custom_value(jQuery-element, “get”) returns the value of the custom element that should be posted to the server.

And it appears that the corresponding “set” is supposed to set the value in the form… but unless Im very confused its completely broken…

At line 766 of grid.formedit.js we have:

var dummy = cm.editoptions.custom_value($(".customelement",this),'set');

Problem is that “this” is actually the corresponding “td” cell – which probably doesnt /have/ a child with class “customelement”.Even if it did, we wouldnt know which custom element we're supposed to be setting the value of (or, on the other hand, if “this” were the span containing the custom element, we wouldnt know what value to set it to!).

I think its supposed to be

var dummy = cm.editoptions.custom_value($("#"+nm,"#"+fmid),'set',tmp);

Where tmp /is/ the unformatted value of the cell.

So, in other words, apart from the naming convention (and the bug!), everything is supposed to work the way we both want anyway…

Mark

Basically, the custom_value function has two purposes, one to get the value from the form, and post it to the server, and the other to put the value into the form.

Rather than two functions, its a single function, and the second parameter is either “set” or “get” to control which operation it performs.

But basically “get” is your custom_value, and “set” is your custom_format.

The problem is that the call to “set” from fillData is broken, and cant possibly work (again, assuming Im not just confused). So right now, to use a custom element you have to use { recreateForm:true }.

Mark