Announcement

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

    Time portion of DateTime ignored in ListGrid Cell editing

    Hi,

    We have a databound ListGrid with some fields of type "datetime".
    In grid's setEditorCustomizer we're returning TextItem for these fields. That TextItem has its setEditorValueFormatter and setEditorValueParser overriden to do time zone processing, validation, etc.

    This whole thing worked fine in SmartGWT3.1 and even in our initial eval download of SmartGWT6.1 on Nov 29.
    But with the latest builds (downloaded yesterday, and in mid February before that) we're seeing the following strange behavior:

    If we edit date portion of datetime everything is fine. If we edit time portion of this - time value gets ignored, setEditorValueParser receives old value in parseValue.

    In the last build I removed TextItem to use DateTimeItem instead, but problem persists. Meanwhile it all works ok for date and time if DateTimeItem is in the DynamicForm...

    Any insight is greatly appreciated.

    Thanks

    -sarkis



    #2
    The point of an editValueParser is to immediately receive the value entered by the user without any pre-processing, and we already have automated tests that verify this behavior, so we will need a minimal, ready-to-run test case in order to investigate this as a possible framework problem.

    Comment


      #3
      I wrote the following small chunk of code that demonstrates the problem for me:

      Code:
       window = new Window();
      window.setHeight(100);
      window.setWidth(200);
      ListGridField timeTest = new ListGridField("timetest", "TimeTest");
      timeTest.setType(ListGridFieldType.DATETIME);
      timeTest.setCanEdit(true);
      ListGrid grid = new ListGrid();
      grid.setWidth100();
      grid.setHeight100();
      grid.setCanEdit(true);
      grid.setFields(timeTest);
      grid.setEditorCustomizer(new ListGridEditorCustomizer() {  
           @Override    public FormItem getEditor(ListGridEditorContext context)    {       return new DateTimeItem();    } });
      
      Record record = new Record();
      record.setAttribute("timetest", new Date());
      grid.setData(new Record[] {record});
      window.addItem(grid);
      window.show();
      And I see the problem even without specifying EditorCustomizer. When value is still in the FormItem it is properly updated, but when it's put back into grid time change is ignored unless date also changed.

      Thanks!

      Sarkis

      Comment


        #4
        We aren't seeing any problems running exactly your code against latest 6.1 or 12.0.

        Which locale are you in? Have you loaded a locale in your project? Have you set any global date/time formatters/parsers/inputFormat?

        Comment


          #5
          Locale is 'en'
          I've added LogHelper.log(LocaleInfo.getCurrentLocale().getLocaleName()); to verify that.
          As far as I know we're not setting any global formatting.
          Is there a way to check that too?

          Thanks

          Sarkis

          Comment


            #6
            Hi,
            Is there anything else I can check for this?

            Thanks

            Sarkis

            Comment


              #7
              A few things:

              1) which locale is your browser in? That is, what timezone are you in?
              2) you can tell whether your project installs a locale-file by checking your .html and .gwt.xml files
              3) you would find global formatters being installed at the top of your app, before anything else (at least, that's where they ought to be)
              4) can you confirm that if you import our builtinds sample to a new project and drop your sample code into it, you still see the issue?

              If you still see issues, we'll need more detail on how you're dealing with timezones, that is, what the timezone code you mentioned in your parser is actually doing, because something must be out of sync with the builtin parsers.

              Comment


                #8
                I tried once more with the latest build and it is working fine now. Not sure what was wrong before as none of the other variables changed - same code, same env.
                But, as another info point, it turned out we were not using March build but only one from early February, so if there was any fix done in this area between then and now - it would explain it.
                Otherwise, this will remain a mystery.

                Sarkis

                Comment

                Working...
                X