Announcement

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

    Recursion loop in JS code when changing value in combobox cell editor with DataSource with SmartGWT 6.1

    Hi,

    we are using a ComboBoxItem for one column in a ListGrid as cell editor.
    The data is set by setOptionDataSource(). When the cell is edited, the values (and rendering) is correct. However, when the selected value is changed and should be applied by stopping editing, this exception is thrown:

    ISC_Core.js:1174 *11:44:34.777:MDN3:WARN:Log:RangeError: Maximum call stack size exceeded
    Stack from error.stack:
    isA.Object(<no args: exited>) @ ISC_Core.js:128:774
    .combineObjects(<no args: exited>) @ ISC_Core.js:109:147
    .combineObjects(<no args: exited>) @ ISC_Core.js:110:6
    .combineObjects(<no args: exited>) @ ISC_Core.js:110:6
    .combineObjects(<no args: exited>) @ ISC_Core.js:110:6
    ...

    ... before transformRequest(DSRequest request) is invoked in the DataSource so we cannot find anything related here to our code (and there is no network traffic).

    Always reproducible in Chrome and Firefox, with super dev and compile mode.
    This happens only after updating to SmartGWT 6.1 (GWT 2.8.1) (from 6.0/GWT 2.8.0) without changing anything in our code.

    I can give more detailed information as requested but providing a short code snipped to reproduce seems impossible with everything needed for the dataSource.

    #2
    After inspecting the JS code we have more information: The selectable values in the combobox are not atomic but our own Java class (containing a String and Object field). Somehow this is handled wrong in combineObjects(). We can temporally fix it by overwriting the JS code for combineObjects() to avoid the recursive call here.

    Comment


      #3
      This isn't enough information to go on.

      You should be able to easily create a test case here by just extracting the data your DataSource is returning and sticking that into a client-Only DataSource.

      We're also not clear on what is non-atomic - the values for the declared valueField?

      Further how can this result in revision? Do these non-atomic objects have references to other objects? If so, is that necessary - seems a bad choice.

      Comment

      Working...
      X