Announcement

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

  • Need an OnCellValueChanged Event and its Handler

    Hello Isomorphic,

    We need to implement functionality on a ListGrid such that we react to changes on a Cell (using an event handler). In essence, we simply need to register a handler for an event that fires when a cell changes its value (whether this was through a direct edit (using the field editor), indirect edit (for example Paste, or Ctrl+D, Ctrl+R), or programmatically changed).

    We have tried the following methods, which seemed the closest to what we need, but they don't really give us what we want:

    - ListGridField.addChangeHandler: we can't use this method for our purposes, since
    a) it fires before the cell actually changes (once you enter the Cell Editor, this event fires on every key-stroke)
    b) it does not fire when the user presses escape (cancels the edit)
    c) it does not fire when doing Ctrl+D or Ctrl+R (fill down, fill right)

    - ListGridField.addChangedHandler: same issues as addChangeHandler, plus, it does not provide the old value


    We look at other methods as well (ListGrid.addEditCompleteHandler, ListGrid.addCellSavedHandler) but they don't fire on change (they fire after a data is saved to the back-end). Also ListGrid.addEditorExitHandler, but it doesn't work for us because we need to be notified of changes even if they user does not use an editor to change the value.

    What is your recommendation? Is there an API call to handle this and we simply missed it, or can this be added to your APIs? We're using the latest release (12).

    Thanks!

  • #2
    You are trying to catch multiple different things, so use multiple different handlers.

    Use ChangeHandler, then also add a keypress handler (via editorProperties) since you also want to catch Escape keypresses, which are not changes.

    As far as the “fill” operation, it’s not clear what you want to catch, but a bodyKeyPress handler should work for that.

    Comment


    • #3
      First, thanks for the quick reply.

      Listening for all these different events won't work for us, due to a number of reasons. The main ones being a) we don't want to be listening for key-strokes, we want changes. Key-strokes fire before the changes take effect. b) Performance: we'd be putting a lot of burden listening for a lot of events unnecessarily.

      Maybe this is a better way to convey what we are in need of:

      - The ListGrid does know when a change is made on a cell - we can actually see it on the screen because the cell turns light-blue (flagging the cell as having changes). We know this works in all the cases we outlined above (when editing through a cell Editor, Pasting, Filling-down and/or right, etc.). All we're asking is that when the cell is internally flagged as having changes, the ListGrid would fire an event so we can hook our on handlers and react to these changes. This seems like a useful feature and given that the ListGrid already does the hard part (detecting the changes), firing an event should be not hard to do.

      Thanks!


      Comment


      • #4
        You’re asking for multiple different types of notifications, some are changes, some not (such as escape keypress). Hence multiple event handlers.

        Adding multiple event handlers has negligible performance impact, what matters is the logic you run in response to the event.

        So again, we’ve already provided a correct and working approach.

        Comment


        • #5
          Thanks again. I think our request still may not be clear. We would like to get notified when the cell turns light blue, i.e. when the listgrid register that a cell has changed. I know the ListGrid has this, it's just a matter to give us a handler so we can implement our own logic. It seems like this would be a feature that is easy to implement and other users/customers can benefit from.

          Comment


          • #6
            We have a Feature Sponsorship program for this reason. We would first want to understand why you care about this particular set of conditions, ie, what is the use case from the end user's perspective? Then if it seems like a possibly recurring need it could be a valid Feature Sponsorship.

            Comment

            Working...
            X