Custom CellEditing Break after Upgrading from 3.3 to 5.3

  1. #1

    Custom CellEditing Break after Upgrading from 3.3 to 5.3

    I had the following codes working fine until I upgraded from 3.3 to 5.3 any thoughts? I was able to move to next row same column when inputting values in a grid using these codes. Since the upgrade, I only get moved next row only. Were there any breaking changes?

                                        <ext:Column runat="server" ID="Col6" DataIndex="TOTAL" Text="TOTAL" Width="90" Align="Center">
                                            <Editor>
                                                <ext:TextField ID="TextField5" runat="server">
                                                    <Listeners>
                                                        <SpecialKey Handler="if (e.getKey() === e.ENTER) {this.up('gridpanel').enterWasPressed = true;}" />
                                                    </Listeners>
                                                </ext:TextField>
                                            </Editor>
                                        </ext:Column>
    
                                <Plugins>
                                    <ext:CellEditing ID="CellEditing1" runat="server" ClicksToEdit="1">
                                        <Listeners>
                                            <Edit Handler="if (e.grid.enterWasPressed) {
                                                            this.startEdit(e.rowIdx + 1, e.column);
                                                            e.grid.enterWasPressed = false;
                                                        }" />
                                        </Listeners>
                                    </ext:CellEditing>
                                </Plugins>
    Last edited by geoffrey.mcgill; Dec 23, 2020 at 4:56 PM.
  2. #2
    Hello @garyawalker!

    Quote Originally Posted by garyawalker
    Were there any breaking changes?
    Between every major release there are unavoidable breaking changes. Most of the code becomes the same, and whenever possible from Ext.NET side, we keed code backwards compatible. But sometimes we simply must let old syntax go in favor of new technologies and performance. And major releases are where we let all necessary breaking changes happen. Especially when we are talking about two major version steps ahead.

    In fact, at least one client side method you are relying on is deprecated since Ext JS 5.5. This specific version of Ext JS was never included in Ext.NET 3, which ships Ext JS 5.1.2. Back then, we had a licensing limitation where we could not go further a few minor releases of Ext JS. This is no longer the case and Ext.NET 5 employs Ext JS 7.3.1 and will be upgraded to latest as it is released.

    After some investigation I found that the Edit event is simply not being fired, as the edit-start is being fired by itself before it completes. Events changed dramatically since Ext.NET 3 and seems like the change implied this "loop guard" of events (not firing themselves indirectly).

    The easiest solution I found was to delay and separate the new "start edit" call outside the edit event, letting it finish in the cell currently changing. This may not affect anything in your scenario, but feels safer to let the edit finish its full cycle before starting a new one, right?

    To do so, you can just change line 5 in your second code block to this:

    Ext.defer(function() { this.startEditByPosition({ row: e.rowIdx + 1, column: e.colIdx }) }, 1, this);
    Here, I abandoned the deprecated startEdit() method with the still supported startEditByPosition() one, which seems even better for the job, as you just pass row and column indexes as references of where to move the editor to.

    I am also using the Ext.defer() method with just 1ms delay, meaning it will just queue the function to be called as soon as possible when the current running task is done. Also important here, I provided this as the scope parameter (last this in the line), else, within the function body, it would reference window instead. If you use zero as the time delay, it would get inline-called (not deferred at all) and the same issue will happen.

    The e variable is still preserved in the function call, but it may have been a dangerous move. If this proves inconsistent, you may want to pass/store the current row and column indexes in the this scope and then reference them within the deferred function.

    Well, hope this helps!
    Fabrício Murta
    Developer & Support Expert
  3. #3
    Hi Fabricio!

    Thanks for your very comprehensive explanation and most importantly the solutions that worked like a charm. Blessings

    Please mark as closed

Similar Threads

  1. [CLOSED] 4.8 (latest) break internet explorer
    By Z in forum 4.x Legacy Premium Help
    Replies: 9
    Last Post: Aug 28, 2019, 6:39 AM
  2. [CLOSED] Convert RowEditing Plugins to CellEditing CellEditing
    By Alaswad in forum 3.x Legacy Premium Help
    Replies: 5
    Last Post: Aug 23, 2016, 1:09 PM
  3. [CLOSED] Did Charts break
    By randy85253 in forum 1.x Legacy Premium Help
    Replies: 8
    Last Post: Sep 05, 2013, 8:18 PM
  4. How to not break the back button inside a viewport?
    By netwearcdz in forum 1.x Help
    Replies: 0
    Last Post: Oct 22, 2009, 7:58 PM
  5. [CLOSED] no line break in text area
    By Sharon in forum 1.x Legacy Premium Help
    Replies: 5
    Last Post: Aug 07, 2009, 5:53 AM

Tags for this Thread

Posting Permissions