You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Once the editor box is displayed, click somewhere inside the editor box, or change the value thru the buttons inside it. You can click and the editor is only dismissed once you click outside the box (or hit Esc).
b. bad behavior
Expand one of the employees clicking on the [+] icon
Click a cell in the 'Quantity' column.
Once the editor box is displayed, by clicking anywhere inside the editor area dismisses the editor as if the click was outside the editor.
Debugging
Debugging this issue is not trivial. It is needed to add breakpoints that trigger in more than one hit, so you can click the cell (so it is displayed) and then have the breakpoint trigger the moment it is mis-dismissing the editor.
Good values are to trigger the breakpoint in 2 or 4 hits of the point.
To get to where the code differs, add a breakpoint to trigger every 4th hit (when multiple of 4) on Ext.View.View.handleEvent() (~ line 95236 of ext-all-debug.js).
Notice how e.item receives a value when the breakpoint is hit when clicking the broken field (b: bad behavior above). In contrast, e.item does not return anything when clicking the working field (a: good behavior above).
The item is returned in the line which reads e.item = e.getTarget(me.itemSelector);; getTarget calls Ext.dom.Element.findParent() which in turn, cycles all parents of the clicked grid cell until
For (a), it reaches the topmost <HTML> node of the document.
For (b), it reaches a <TABLE> element with ID tableview-1018-record-1, for which the click is forwarded. As the click focus somewhere else, the edit controller loses focus consequently hiding back.
The text was updated successfully, but these errors were encountered:
##Workaround
In order to exempt editor controls from traversing all the way thru the table view layer (which is the selectable control), you can limit de depth of the search with the following override.
The value of 12 was found on trial-and-error. When depth == 13 is the point where the code finds the "clickable" layer and moves the focus out.
The workaround above will exempt any controls that are from the CellEditing (or RowEditing) plugins from seeking deeper than 12 HTML nodes' depth for clickable stuff.
While this does not break/fix other controls, it also does not disallow any expected interaction of the editors with sub-controls down to nearby the sub-table view layer that RowExpander creates.
This issue can be interpreted as an incompatibility between the Cell Editor and Row Expander plugins.
For a permanent fix, one choice is to have this override take place whenever Ext.grid.plugin.CellEditing is used.
Fixed in the revision 6465 (trunk). It goes to 3.2.0.
The bug has been fixed on the level of Ext.view.View. There was already a check to make an outer GridPanel ignoring events from its inner GridPanel, but it was not enough for this scenario. So, I added an additional check and it appears to behave fine. Please let me know if you find a scenario where it breaks.
This bug is no longer reproducible when merged ExtJS 6.2.0 to Ext.NET! Tested both main case and related issue with combo box (refer to second forum thread mentioned on first post).
Overview
This bug was reported on the forum thread: CellEditor in RowExpander not behaving as in parent GridPanel
Update by @DaniilVeriga:
If fixed in SVN ever, it would be nice to update this forum thread as well.
http://forums.ext.net/showthread.php?59569
End of the update
Code to reproduce issue
Steps to reproduce
Steps to reproduce:
a. good behavior
b. bad behavior
Debugging
Debugging this issue is not trivial. It is needed to add breakpoints that trigger in more than one hit, so you can click the cell (so it is displayed) and then have the breakpoint trigger the moment it is mis-dismissing the editor.
Good values are to trigger the breakpoint in 2 or 4 hits of the point.
To get to where the code differs, add a breakpoint to trigger every 4th hit (when multiple of 4) on
Ext.View.View.handleEvent()
(~ line 95236 of ext-all-debug.js).Notice how
e.item
receives a value when the breakpoint is hit when clicking the broken field (b: bad behavior above). In contrast,e.item
does not return anything when clicking the working field (a: good behavior above).The item is returned in the line which reads
e.item = e.getTarget(me.itemSelector);
; getTarget callsExt.dom.Element.findParent()
which in turn, cycles all parents of the clicked grid cell until<HTML>
node of the document.<TABLE>
element with IDtableview-1018-record-1
, for which the click is forwarded. As the click focus somewhere else, the edit controller loses focus consequently hiding back.The text was updated successfully, but these errors were encountered: