Custom CellEditing Break after Upgrading from 3.3 to 5.3

[garyawalker]

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>

[fabricio.murta]

Hello @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 (https://docs.sencha.com/extjs/7.3.1/classic/Ext.grid.plugin.CellEditing.html#method-startEdit). 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 (https://docs.sencha.com/extjs/7.3.1/classic/Ext.grid.plugin.CellEditing.html#method-startEdit) with the still supported startEditByPosition() one (https://docs.sencha.com/extjs/7.3.1/classic/Ext.grid.plugin.CellEditing.html#method-startEditByPosition), 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 (https://docs.sencha.com/extjs/7.3.1/classic/Ext.html#method-defer) 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!

[garyawalker]

Hi Fabricio!

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

Please mark as closed