When initiating an inline edit with, for example, edit types “ed,ed,ro,ed” for a 4-column grid, and when tabbing out of the second column, should I expect the editor to open up in column 4? When I try this the tab out of the second column goes to the third column, but it’s not visually evident that that is where the focus is, so it can be a bit confusing, and it’s only if you tab yet again that the editor opens up in column 4. It seems more reasonable to me (though perhaps Im missing something) to have a tab out of the second column go straight to the fourth.
This is optional behavior, it can be enabled by using
grid.enableEditTabOnly(true);
Oh! Very cool. Thanks.
Additional development reveals that “sub-row” fields are not skipped as are “ro” fields. The documentation for enableEditTabOnly states that it “enables/disables (edit) mode when readonly cell is not available with tab.” Is this the intent? Would it not be appropriate to also skip sub-row and sub_row_ajax cells?
While it be a separate issue, I noted that the subrow is collapsed as soon as the editor for the first column of the main row is opened. This is a curious behavior. Is there a reason for this?
Additional development reveals that “sub-row” fields are not skipped as are
Please try to update existing js file with attached one.
Actually sub-rows cells must be counted as readonly cells and excluded from tab order.
This is a curious behavior. Is there a reason for this?
Many types of editor can render self correctly when sub-row is opened ( they overlap part of sub-row ), to prevent it, sub-row closes on edit-start.
dhtmlxgrid_excell_sub_row.zip (9.5 KB)
Thanks for providing the new version. It did not seem to have any effect. When starting the edit process, the subrow column still seems to be set as the starting point. When then hitting Tab, the first visible column opens up for edit. Let me provide more background about what I’m up to as it may be of assistance. I have a context menu that includes an “Edit” option. When that is selected I perform certain tasks (such as saving all current row values, in case the user aborts the edit by pressing the Esc key). I then initiate the grid edit follows:
grid.lockRow(gridRowId, false);
grid.selectRowById(gridRowId);
grid.editCell();
When this code is used in a grid that does not have a subrow, it works as desired. That is, the first column is opened up for editing. But when the subrow is included, it seems, as I said earlier, that the active cell is the subrow “cell” since a single tab then causes the first visible cell to open up for edit.
I also tried
grid.lockRow(gridRowId, false);
grid.selectCell(gridRowId,1);
grid.editCell();
I also tried modifying tab order, setting the first column (subrow) order to zero.
I also have true in the XML stream but, true or false, it doesn’t seem to affect the symptoms described here.
Thanks for all the help, but I’ve decided to abandon inline edit in favor of using separate windows for editing.