[Isomorphic]

OK, so this new report - which doesn't involve server-generated fields at all - make sense. We're looking at modifying fieldValuesAreEqual() so that it will always look up DataSource fields in addition to fields configured on the form (or any other DataBoundComponent).

Just to make sure, can you confirm that the original bug report of a problem with server-generated datetime fields was not actually real?

It's a little confusing, since the *second* time you tried to save, you'd hit the bug we're now correcting. But there does not appear to be an issue with server-generated fields as you were originally reporting.

[antanas.arvasevicius]

Hi, sorry for that, yes, it was not related to server-side as previously mentioned,
I just thought that it was so, but during investigation it seems not related to server response at all. I just misinterpreted the sources. Next time I'll try to set up test case first, before posting an issue and thank you for fix.

[Isomorphic]

We just applied some framework changes as we described - fieldValuesAreEqual() now supports detecting an associated field object which exists only in the DataSource, as well as visible or hidden fields on the DBC itself.

We also added some custom date-comparison logic in the case where the passed field really isn't available, and both passed values are Date instances.

You can test these changes with a build dated August 23 or later.

Yes, test-cases are almost always the quickest way forward - part of the reason we ask for a standalone test-case, using clientOnly DataSources, etc, is that producing such a test-case often leads to a solution, indicating bugs or misuse in application code, rather than framework code.

[antanas.arvasevicius]

Ok, I'll test it, thank you.

But is it okay to completely cancel rememberValues() then at least one field somehow do not match?
Lets imagine if I would implemented highlighting of which field was changed but not saved, then I edit couple of fields, and during saving I edit one field more (and if it triggers that skip remember values logic), my UI still shows that all couple of fields are edited and not saved. But truly they are sent to server and persisted, just one field which was edited during save was not submitted and only that field must be returned by valuesHaveChanged(true). Don't you think so?

[Isomorphic]

The normal behavior of saveData() is that editing is blocked while saving occurs, and we recommend keeping it that way for almost all applications.

If you have a specialized use case where it makes sense to edit during a save, you could compute which values have changed and use rememberValues() with the save set in order to implement the interface you describe.

[antanas.arvasevicius]

Hi,
no, I'm just saying that it's not logically correct to skip rememberValues() for all fields then you encounter a change in at least one field

// ISC_DataBinding.js: _saveDataReply : function (request, response, data) {

                } else {
                    // value in the form has changed since being submitted
                    rememberValues = false;
                }

Should be:

                } else {
                    // value in the form has changed since being submitted
                    rememberValues = false;
                    rememberValuesExcludedFields.push(fieldName); // put fields which has a not intended change.
                }

and then later:

            if (rememberValues)  {
                this.rememberValuesExceptThese(rememberValuesExcludedFields); // instead of: this.rememberValues();
            }

It's my thoughts. Because other fields WAS sent to server and correctly persisted, so they must be remembered.

[Isomorphic]

There's a few different reasons for calling or not calling rememberValues() - change detection is one, another is what happens on reset, and also how defaultValues are handled. We can't really get into all the scenarios that influence this particular code path here, but again, thanks for bug report regarding undeclared date fields and change detection.

[antanas.arvasevicius]

no prob, glad I can be helpful somehow for smartclient's framework:) btw, what's the difference between 10.0 and 10.1 released? would you recommend to switch to 10.1?

[Isomorphic]

At this point, other than some enhancements to tools, we are just fixing bugs for 10.1, so it is relatively stable. If you can tolerate the occasional bug (and ideally, report it well on the forums), then it probably makes sense to work with 10.1, both to get the new features and to benefit from miscellaneous non-feature improvements like performance tweaks and expanded documentation in various areas.