Announcement

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

    TextItem with KeyFilter or CharacterCasing does not fire Event for BackSpace

    Well, this is complicated to explain but:


    I have a textField

    TextItem phoneTextIem = new TextItem("PhoneItem", " Phone ")
    phoneTextItem.setKeyPressFilter("[0-9.]");

    phoneTextItem.addChangedHandler(new ChangedHandler()
    {
    @Override public void onChanged(ChangedEvent event)
    {
    //this event will reveal the resulting value as a consequence of the change.
    if(event.getValue == null || event.getValue().toString().isEmpty())
    //Do Something Wonderfull
    }
    });


    I have another TextItem upon which I set: setCharacterCasing(CharacterCasing.UPPER);


    when values either of these 2 textItems becomes empty, due to user backspace, I want the ChangedEvent to fire.
    But the changed event does NOT fire.

    If I do not setKeyPressFilter("[0-9.]" or setCharacterCasing(CharacterCasing.UPPER)
    Then the ChangeEvent fires.

    How can I have the KeyPressFilter and the CharacterCasing on the textItems and catch the ItemChanged event when the BackSpace is used to empty either field.

    I need to know the value of the TextItem that will result as a consequence of user input.

    I hope this is clear.

    #2
    You forgot your version - this bears some resemblance to a bug fixed for 10 and 10.1 in December 2015.

    Aside from that, are you expecting the ChangeEvent to fire when the field *is already empty* and backspace is pressed again? Because it should not actually fire in that circumstance (no change has occurred). If that's your requirement, you probably want a keyPress or keyDown handler instead.

    If you are expecting a ChangeEvent for the backspace that changes the field from one character to zero characters, that should fire a ChangeEvent - but here, we need you to try the latest patched version to see whether your bug is already fixed.

    Comment


      #3
      the SmartGwt verision is 5.0p
      GWT 2.7.0
      Java 1.8

      Comment


        #4
        Always post your complete version including date (not just 5.0p).

        You should try the latest patched build. If this doesn't already resolve the issue, we need answers to the other questions above.

        Comment


          #5
          SmartGWT version: 5.0-p20150816

          Comment


            #6

            Aside from that, are you expecting the ChangeEvent to fire when the field *is already empty* and backspace is pressed again? Because it should not actually fire in that circumstance (no change has occurred). If that's your requirement, you probably want a keyPress or keyDown handler instead.


            No, as I say again,

            TextItem phoneTextIem = new TextItem("PhoneItem", " Phone ")
            phoneTextItem.setKeyPressFilter("[0-9.]");


            Now, the phoneTextItem has data, the user highlights the *entire string* and then presses backspace.
            When this occurs I would expect an item changed event to fire *but it does not*.

            We are not allowed to incorporate patch releases owning to possible instability. We can only use full point releases.

            The issue here has something to do with the interaction of phoneTextItem.setKeyPressFilter("[0-9.]") and the highlighting of the entire string and using the backspace to delete the contents.

            We pay for support. You are not giving us support. You are not even understanding the issue as I have painstakingly written up. Telling me to download the latest patch is not an answer that is only Isomorphic dancing.
            Last edited by siegersallee; 23 Mar 2016, 03:18.

            Comment


              #7
              We're not sure what "Isomorphic dancing" is but it sounds like it could be fun!

              To clarify support:

              1. the onus is on you to avoid filing duplicate bugs by testing the fully patched version. This is industry-typical

              2. patches are provided via dated builds and our versioning convention does not include a "point release" per se. If you need to declare to higher-ups that a "point release" is being used, use the build date as the point release version, if you like. This is also becoming industry typical; a lot of version numbers we see these days end in dates or numbers clearly derived from the date (eg day of year)

              3. please make sure you post your full version in the future. We needed to ask twice for this basic information, and we needed to remind you to answer clarifications. Maybe you think you were perfectly clear in your first post; this doesn't mean you get to just ignore a request for clarification. The entirety of the delays of to this point has been just Isomorphic waiting for you to answer questions.

              So with all that out of the way...

              We are seeing that Change fires in all version, the difference is, Change does not fire until blur in 5.0 (it fires immediately in 5.1 and 6.0). The KeyPress event does fire.

              So we'd recommend either:

              1. update to 5.1 (or even 6.0) now - you should definitely do this if you are in active development

              OR

              2. use the keyPress event in this case since you want to take action earlier than blur

              Let us know if this is intractable for some reason. We really recommend the move to 5.1. This is the first of several issues you might hit that are already solved in later versions.

              Comment

              Working...
              X