SmartClient Version: v9.1p_2014-05-20/PowerEdition Deployment (built 2014-05-20)
and
SmartClient Version: v9.1p_2014-05-27/PowerEdition Deployment (built 2014-05-27)
Tested with chrome, safari on mac osx
while migrating an app from 9.0 to 9.1, I found a problem with ComboBoxItems of some forms managed by a ValuesManager.
My code calls valuesManager.editRecord, and only after that will decide if the forms have to be readOnly or not, and so will call form.setCanEdit.
The problem is that (with 9.1) the ComboBoxItems remain editable (formItem.getCanEdit() returns true) even after calling form.setCanEdit(false)
I managed to find the difference respect to 9.0: the method at line 23696 in ISC_Forms.js:
in that method there's a call to this.setCanEdit(true); (which happens before my call to form.setCanEdit(false))
but the problem is that after calling formItem.setCanEdit(), the item remains editable even after calling form.setCanEdit(false)
So my question is: is it intended behavior that after a call to formItem.setCanEdit() the item gets insensitive to form.setCanEdit()? I'm asking because that behavior is the same as in 9.0.
If yes, the methods _setLoadingDisplayValue/_clearLoadingDisplayValue are actually creating a problem in my use case. Would you fix that?
As per the documentation of loadingDisplayValue, setting it to null solves my problem (I think that _setLoadingDisplayValue/_clearLoadingDisplayValue methods doesn't get called).
If you won't fix that, however, it would be nice to have the option to set loadingDisplayValue at the form level.
and
SmartClient Version: v9.1p_2014-05-27/PowerEdition Deployment (built 2014-05-27)
Tested with chrome, safari on mac osx
while migrating an app from 9.0 to 9.1, I found a problem with ComboBoxItems of some forms managed by a ValuesManager.
My code calls valuesManager.editRecord, and only after that will decide if the forms have to be readOnly or not, and so will call form.setCanEdit.
The problem is that (with 9.1) the ComboBoxItems remain editable (formItem.getCanEdit() returns true) even after calling form.setCanEdit(false)
I managed to find the difference respect to 9.0: the method at line 23696 in ISC_Forms.js:
Code:
_clearLoadingDisplayValue : function (notFoundCount) { // The message clears itself because of the new value assigned (or reverts to // original value in the case where no new value was assigned), however, // if the field was set to read-only during Loading message, make it editable now if (!this._fetchMissingValueInProgress()) { if (this._readOnlyFetchMissingValue) { if (notFoundCount && notFoundCount > 0) this._skipCheckForDisplayFieldValue = true; this.setCanEdit(true); delete this._readOnlyFetchMissingValue; } this._showingLoadingDisplayValue = false; } }
but the problem is that after calling formItem.setCanEdit(), the item remains editable even after calling form.setCanEdit(false)
So my question is: is it intended behavior that after a call to formItem.setCanEdit() the item gets insensitive to form.setCanEdit()? I'm asking because that behavior is the same as in 9.0.
If yes, the methods _setLoadingDisplayValue/_clearLoadingDisplayValue are actually creating a problem in my use case. Would you fix that?
As per the documentation of loadingDisplayValue, setting it to null solves my problem (I think that _setLoadingDisplayValue/_clearLoadingDisplayValue methods doesn't get called).
If you won't fix that, however, it would be nice to have the option to set loadingDisplayValue at the form level.
Comment