Announcement

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

    ListGrid.hasChanges() is inconsistent?

    ListGrid.hasChanges() detects a change in DateItem fields even if the user
    does not actually make any changes in the cell, i.e. the user selects the cell
    for editing, but navigates away from the cell without editing. Cells with
    String or float values act as expected: hasChanges() is not triggered by
    this behavior.

    Is this a bug? I guess I need to explicitly check DateItem fields for changes?

    I don't have a dataSource, so I think I need to manually check for changes
    and then apply the changes myself. I think ListGrid.hasChanges() would
    work but I don't want to detect non-existant changes.

    Code:
    <cut>
            ListGrid listGrid = new ListGrid();
            listGrid.setWidth(800);
            listGrid.setHeight(224);
            listGrid.setShowAllRecords(true);
            listGrid.setCanEdit(true);
            listGrid.setEditByCell( true);
            listGrid.setEditEvent(ListGridEditEvent.DOUBLECLICK);
    
            listGrid.setFields( getFields());
            listGrid.setCanResizeFields(true);
    
            listGrid.setAutoSaveEdits( false);
    
            listGrid.addEditorExitHandler(new EditorExitHandler() {
    
                @Override
                public void onEditorExit(EditorExitEvent event) {
    
                    if( listGrid.hasChanges()) {
                        Window.alert("has changes");
                        // let the user cancel or save changes here.
                    }
                }
    
            });
    
            listGrid.setData( getRecords());
            // getRecords return ListGridRecords with
            // startTime attribute being java.util.Date
            // name attribute is String
            // distance attribute is float.
    
    <cut>
    
        public ListGridField[] getFields() {
            ListGridField[] fields = new ListGridField[3];
            fields[0] = new ListGridField("name", "Name");
            ListGridField field = new ListGridField("startTime", "Date");
            DateItem dateItem = new DateItem();
            dateItem.setDateFormatter( DateDisplayFormat.TOJAPANSHORTDATE);
            field.setEditorType( dateItem);
            field.setCellFormatter(new CellFormatter() {
                public String format(Object value, ListGridRecord record, int rowNum, int colNum) {
                    if (value == null) {
                        return null;
                    }
                    if (!(value instanceof Date)){
                        return value.toString();
                    }
                    return DateTimeFormat.getFormat("yyyy-MM-dd").format((Date) value);
                }
            });
            fields[1] = field;
            fields[2] = new ListGridField("distance", "Distance");
            return fields;
        }

    #2
    I'm having the same problem with date fields but using a valuesManager, not a ListGrid. ValuesManager.valuesHaveChanged() returns true, but ValuesManager.getChangedValues() returns an empty Map.

    If I compare ValuesManager.getOldValues() with ValuesManager.getValues() I can see that the only difference is that the Map returned by getOldValues() includes four Date fields that are included in the Map with a value of null but the Map returned by getValues() does not contain those fields at all, which may may be what is causing valuesHaveChanged() to return true?

    This is after calling ValuesManager.editRecord() but before doing anything to change the values in any of the form items being tracked by the values manager.

    Comment


      #3
      Hi Guys
      This is probably 2 separate issues.

      drm: The issue with the list grid edit values is probably due to the fact that the DateItem editor produces java.util.Date values with time (hour, min, sec, ms) zero'd out in local time. If the java.util.Date values you are passing in do not have local time zero'd out they'll be detected as having been changed by the editor.
      We're making a change to avoid this for logical date fields (fields where listGridField.setType(ListGridFieldType.DATE); has been called) but regardless if you zero out the time component of your date values in your records the problem will likely go away.
      If this doesn't fix it please post a complete test case we can run.

      jay: We're not seeing this behavior in a simple test case. Can you show us sample code? Ideally a simple standalone test case we can use to reproduce the issue, but failing that, the DynamicForm definition, the valuesManager definition, any relevant DataSources and the logic that calls editRecord on the VM?
      Also any steps that seem relevant (For example -do you have to tab through the form items or perform any other user interaction before you get the bug, or can you literally call 'editRecord()' followed immediately by 'valuesHaveChanged()' and see the problem?)

      Regards
      Isomorphic Software

      Comment


        #4
        [UPDATE]: Jay: We are now reproducing your issue. Sorry for the confusion. We'll let you know when we have more concrete information.

        Comment


          #5
          Jay - we believe we've now found and fixed the issue which was making vm.valuesHaveChanged() unreliable in SGWT. Please try the next nightly build and let us know if this continues to be a problem

          Comment


            #6
            SmartClient Version: SC_SNAPSHOT-2011-02-12/PowerEdition Deployment (built 2011-02-12)

            I'm still seeing the same problem. VM.valuesHaveChanged() returns true but VM.getChangedValues() returns an empty map. My workaround for now is to check VM.getChangedValues().isEmpty() instead of valuesHaveChanged().

            Comment


              #7
              Hi Jay
              Ok we've got a reproducible case of this issue now. We'll let you know when we have a solution. In the meantime your workaround should be fine

              Thanks
              Isomorphic Software

              Comment


                #8
                Ok this should be fixed in the next nightly

                Comment


                  #9
                  I'm still seeing this in SmartClient Version: SC_SNAPSHOT-2011-02-19/PowerEdition Deployment (built 2011-02-19)

                  Comment

                  Working...
                  X