Announcement

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

    SmartGWTEE 12.0p - Calendar widget error on Date field with "useTextField=true" and a "required" validator

    isc Version: v12.0p_2019-03-28/Enterprise Deployment
    GWT Version: 2.7.0
    Browser: Chrome Version 73.0.3683.86 (Official Build) (64-bit)
    OS: Windows 10
    SuperDevMode

    Hello, I am seeing a problem where the Calendar widget closes automatically when attempting to use a date field with a text field editor and a "required" validator. Below are the steps to reproduce this by modifying the built-in-ds sample.

    1. In /war/ds/supplyItem.ds.xml, I modify the "nextShipment" field as follows.
    Code:
        <field name="nextShipment"  type="date" title="Next Shipment" useTextField="true">
            <validators>
                <validator type="required" errorMessage="test" clientOnly="true" stopIfFalse="true" stopOnError="true" validateOnChange="true"/>
            </validators>
        </field>
    2. I start the program and go to "Office Supplies"

    3. I click the "Next Shipment" date chooser widget. The calendar opens and closes immediately with the "test" error defined in the validator. I can still type a date manually but cannot use the date chooser. However, if the field is already populated, I can use the date chooser without issue -- I only get the error when the text field is empty.
    Click image for larger version

Name:	date_validator_error.png
Views:	105
Size:	69.8 KB
ID:	257287

    I observe this behavior with both datetime and date fields. I see it in SmartGWT v12.0 and v6.1, but not in SmartGWT v6.0 (in v6.0 I can use the date chooser widget successfully on an empty field with this validator configuration). Can you let me know if the new behavior is unexpected, or if I need to change the validator in some way to make it compatible with date items?

    Thank you!

    #2
    Thanks for the notification and the very clear test case.
    We see the issue and have a fix for it in the 12.1d branch (that will be present in builds dated April 5 and above)
    We will port the fix back to 12.0 and 6.1 in the near future. (In the meantime the simplest workaround would be to set stopOnError to false for the field in question)

    Regards
    Isomorphic Software

    Comment


      #3
      Just tested this with v12.0p_2019-05-04 and it looks to be fixed. Thanks!

      Comment

      Working...
      X