Hello,

Thank you for reaching out to us regarding the issue you've encountered with the collapsible group of columns in the igx-grid component. I understand when editing a row and interacting with the expand/collapse icon inadvertently triggers the RowEditExit event, potentially leading to the loss of entered information.

Let's delve into the intricacies of the default behavior and why it triggers the RowEditExit event. The igx-grid component with collapsible column groups is designed to dynamically render columns and displayed records upon expansion or collapse. This dynamic rendering process necessitates triggering events such as RowEditExit to maintain consistency in data representation. Thus, when a column group expands or collapses, the grid re-renders its columns and the displayed records, inadvertently triggering the RowEditExit event because when you are in edit mode and the columns re-render the edit mode end.

I have been looking into your question and to address your requirement of maintaining the edit mode regardless of the collapse state, let's explore a comprehensive solution:

1. Track Editing State: We'll begin by implementing logic to track the editing state of rows and cells. When a user starts editing a cell, we'll capture the ID of the edited row and the edited column.
2. Handle Expand/Collapse Events: Next, we'll set up event handlers to detect when a column group is expanded or collapsed. Upon detecting these events, we'll set a boolean flag to indicate whether the grid is being expanded or collapsed.
3. Re-Enable Editing Mode: When the RowEditExit event is triggered and the grid is in the process of expanding or collapsing, we'll utilize a setTimeout function to re-enable the editing mode for the previously edited cell after a short delay. This ensures that the user's work is not lost, and they can seamlessly continue data entry.

Here's a detailed breakdown of the solution approach:

• Handle events: We’ll handle rowEditEnter, cellEditEnter and rowEditExit events.

<igx-grid
        #grid
        [data]="data"
        height="650px"
        [primaryKey]="'ProductID'"
        [rowEditable]="true"
        (rowEditEnter)="rowEditStart($event)"
        (cellEditEnter)="cellEditStart($event)"
        (rowEditExit)="rowEditExit($event)"
      ></igx-grid>

• rowEditEnter: We'll handle this event to capture the row ID when editing starts.

public rowEditStart(event){
        this.editedRowId = event.rowID;
    }

• cellEditEnter: Similarly, we'll handle this event to capture the edited column when cell editing starts.

public cellEditStart(event){
        this.editedColumn = event.column.field;
    }

• expandCollapse: This method will handle the expand/collapse events, setting the boolean flag to true.

<igx-icon
              [attr.draggable]="false"
              #target="tooltipTarget"
              [igxTooltipTarget]="tooltipRef"
              [showDelay]="0"
              [hideDelay]="0"
              (click)="expandCollapse()"
              >{{ column.expanded ? 'expand_more' : 'chevron_right' }}
            </igx-icon>

public expandCollapse(){
        this.isExpandOrCollapse = true;
    }

• rowEditExit: Finally, in this method, we'll re-enable editing mode after expand/collapse. If the event is fired and the boolean flag is true, we'll retrieve the cell using the getCellByKey method of the igx-grid component, passing the row ID and the column field as parameters. Then, we'll handle the editMode property of that cell and set it to true, ensuring that the user can seamlessly resume editing.

public rowEditExit(event){
        if (this.isExpandOrCollapse) {
            setTimeout(() => {
                this.grid.getCellByKey(this.editedRowId, this.editedColumn).editMode = true;
                this.isExpandOrCollapse = false;
            }, 100);
        }
    }

By implementing this approach, you'll achieve your requirement of maintaining edit mode consistency in collapsible column groups, ensuring a seamless user experience.

The described scenario could be observed here:

In addition, I have prepared a small sample illustrating this behavior which could be found here. Please test it on your side and let me know how it behaves.

However, it's essential to note that in scenarios where expanding a column reveals new columns or collapsing a column hides the edited column due to the collapsible column groups themselves, this approach may not suffice. When a column is added or hidden, it cannot remain in edit mode. In such cases, additional checks and custom implementation based on your specific logic and code may be necessary to ensure the desired behavior.

Regards,

Georgi Anastasov

Entry Level Software Developer

Infragistics

<igx-icon
    [attr.draggable]="false"
    #target="tooltipTarget"
    [igxTooltipTarget]="tooltipRef"
    [showDelay]="0"
    [hideDelay]="0"
    (click)="expandCollapse(column.expanded)">
    {{ column.expanded ? 'expand_more' : 'chevron_right' }}
</igx-icon>

public expandCollapse(expanded) {
    console.log('Icon clicked.');
    if (!expanded) {
        console.log('Column expanded.');
    } else {
        console.log('Column collapsed.');
    }
    this.isExpandOrCollapse = true;
}

In addition, I have modified my previous sample illustrating this behavior which could be found here. Please test it on your side and let me know how it behaves.

Thank you for your cooperation.

Regards,

Georgi Anastasov

Entry Level Software Developer

Infragistics

I scanned through your discussion so far and in response to your latest comment, I have forked and modified the previously suggested sample with additional logic to tackle this.

As you will see, a workaround approach like this involves some quite verbose code to handle this. Additionally, while there is added additional checks for the add row not to throw the previously encountered error, fully restoring the entered values and adopting the same approach, as for an edited row would not be as straightforward to retrieve the record like this, if at all possible.

Please, note that due to the upcoming national holidays you may experience delay in replies for messages received Friday, 3rd May. Thank you for understanding.

Best regards,
Bozhidara Pachilova
Associate Software Developer