Announcement

Collapse
No announcement yet.
X
  • Filter
  • Time
Clear All
new posts

    bug or problem related to formItem.setCanEdit

    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:
    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;
            }
        }
    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.
    Last edited by claudiobosticco; 29 May 2014, 06:30.

    #2
    We've made a change which should resolve this issue for you.
    Please try the next nightly build dated June 4 or above.

    Regards
    Isomorphic Software

    Comment


      #3
      I've just tested with build:
      SmartClient_v91p_2014-06-04_PowerEdition
      and I see no difference in behaviour.

      Comment


        #4
        SmartClient Version: v9.1p_2014-06-06/PowerEdition Deployment (built 2014-06-06)

        fixed, thank you very much

        Comment

        Working...
        X