Announcement

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

    Bug with filterRow where FormItems become uneditable TextItems

    Hi Isomorphic,

    I just noted a bug after switching from from 5.1p build from August (unfortunately I can't tell you which one exactly) to today's v10.1p_2016-10-16/PowerEdition.
    I did not create a testcase yet, but perhaps you can work with the screen recording as well.

    I have two ListGrids, displaying the data from one DB-View, one filtered to id is null, one filtered to id is not null.
    The drag action in the video is manual and the new record returned from the DSOperation has the id set, making the entry move from one list to another (it's a view, the real operation is done on a table in server side DMI).

    Click image for larger version

Name:	Animation.gif
Views:	12
Size:	60.7 KB
ID:	240825

    This used to work. Now, as you can see, the filterRow changes its design (=is broken, see uneditable values 13, 34) after the operation finishes.
    Do you have an idea what is broken here? There is no message in the Developer Console.

    Thank you & Best regards
    Blama

    #2
    It might be worth a note that the operation I issue from the client is a operationType=custom one.
    I saw that I have the error also when deleting an assignment.

    Best regards
    Blama

    Comment


      #3
      Hi Isomorphic,

      I got it reproduced in your online showcase sample (using v11.0p_2016-10-16, but I'm on 5.1, which has the same bug):

      Run this in Developer Console:
      Code:
      isc_ListGrid_3.setShowFilterEditor(true)
      isc_ListGrid_3.redraw
      Then Drag and Drop a row. Click image for larger version

Name:	Animation.gif
Views:	16
Size:	105.1 KB
ID:	240830


      I tested EdgeHTML 14, FF26, Chromium 53.

      This is a bad one as it will affect many users.
      Could you tell me which is the last build that does not show this error?

      Best regards
      Blama
      Last edited by Blama; 17 Oct 2016, 13:06. Reason: Added used browsers

      Comment


        #4
        Just confirming that we do see this misbehavior - we're looking into it and will update here when we have more information.

        Comment


          #5
          It turns out that this was a one-day regression - it was only present in the build from October 16 - please use the build from the day before, for now, or wait for the next one.

          Comment


            #6
            Hi Isomorphic,

            I can confirm that it does not happen anymore in my application using v10.1p_2016-10-19. I did not retest the Showcase sample, as it is not updated, yet.

            Thank you for the fast fix & Best regards
            Blama

            Comment


              #7
              Hi Isomorphic,

              it is also fixed in the online server showcase sample using v11.0p_2016-10-19.

              Best regards
              Blama

              Comment

              Working...
              X