Announcement

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

    ListGrid Field validators and validateOnChange

    Hi,

    Using SmartClient_v90p_2014-01-24_Pro (Google Chrome), I'm having an issue with ListGrid fields onto which I
    attach a validator and for which the listGrid is configured with validateOnChange.

    The problem is that the validation doesn't **ALWAYS** fire onChange. Sometimes it does,
    sometimes it only fires when I leave the field.

    Here are the steps to reproduce a 1st way this problem manifests itself:

    1) Click on one of the row's POPULATION column and enter value 12345 ... not pressing tab/enter (should trigger validation message, but doens't) <-- PROBLEM HERE
    2) When you try tabbing outside the field, the validator kicks in

    Here are the steps to reproduce a 2nd way this problem manifests itself:

    1) Click on one of the row's POPULATION column and enter value 123 ... not pressing tab/enter (which is valid since validator max is set to 999)
    2) Press the tab key to move to the X column and enter value 123 ... not pressing tab/enter (also valid)
    3) Press shift-tab to move back to the POPULATION column
    4) Enter the value 12345 (should trigger validation message, but doens't) <-- PROBLEM HERE
    5) When you try tabbing outside the field, the validator kicks in

    If you try the following scenario, it works as expected:

    1) Click on one of the row's POPULATION column and enter value 123 ... not pressing enter (which is valid since validator max is set to 999)
    2) Press the tab key to move to the X column and enter value 12345 (validation gets triggered as expected, before the user even needs to move outside the field)


    We'd like it to always behave like in the 3rd scenario. Is there some combination of boolean flags or other switches that are required and that we're not using properly?

    Here's a test bed to reproduce the above scenarios (from Featured Samples -> Grids -> Editing -> Edit by cell):

    Code:
    isc.ListGrid.create({
        ID: "countryList",
        width:550, height:224, alternateRecordStyles:true, cellHeight:22,
        // use server-side dataSource so edits are retained across page transitions
        dataSource: countryDS,
        // display a subset of fields from the datasource
        fields:[
            {name:"countryCode", title:"Flag", width:40, type:"image", imageURLPrefix:"flags/16/", imageURLSuffix:".png", canEdit:false},
            {name:"countryName"},
            {name:"continent"},
            {name:"member_g8"},
            {name:"population", type: 'integer', validators : [{ type : 'integerRange', min : 0, max : 999, validateOnChange : true, stopOnError : true }] },
            {name:"x", type: 'integer', validators : [{ type : 'integerRange', min : 0, max : 999, validateOnChange : true, stopOnError : true }] },
            {name:"y", type: 'integer', validators : [{ type : 'integerRange', min : 0, max : 999, validateOnChange : true, stopOnError : true }] },
            {name:"independence"}
        ],
        autoFetchData: true,
        canEdit: true,
        editEvent: "click",
        editByCell: true,
    stopOnErrors : true,
    validateByCell : false,
    validateOnChange : true
    })
    Thanks,

    #2
    Sorry, I posted this in the wrong forum. It should have been posted in the SmartClient Technical Q&A,
    not Smart GWT Technical Q&A ...

    Anyways, it appears that the problem is related to the following, in ISC_Grids.js (43,314):

    Code:
    handleEditorChanged : function (item) {
    
        if (this._drawingItem == item) return;
    
    ...
    
        if (validateOnChange) {
    ...
            this.validateCell(rowNum, fieldName, false, true);
    ...
    }
    It seems that in cases where our validation fails to execute, the above IF condition evaluates to TRUE, therefore
    the code further in that method that would have called validateCell(...), is never reached.

    How can this be resolved ?

    Thanks,

    Comment


      #3
      This has been assigned to a developer for investigation. We'll follow up when we have more information.

      Regards
      Isomorphic Software

      Comment


        #4
        Thanks for the clear test case and analysis. We've found and fixed a framework problem which was causing this issue. The fix will be present in the next nightly build, dated April 1, in the 9.0p, 9.1d and 10.0d branches.

        Also as an aside - if you're doing new development we always recommend you move up to the latest stable branch (so 9.1p rather than continuing to develop on 9.0p)

        Regards
        Isomorphic Software

        Comment


          #5
          Great, we'll test this when we grab that latest build.

          Thanks!

          Comment

          Working...
          X