Hi,
In our project we are using a collapsible group of columns. When adding a new row, it seems that if you interact with the expand/collapse icon, the RowEditExit event is triggered, so if someone gets halfway through entering information and decides to expand or collapse those columns (some of which are editable) this loses their work. Is there any way to prevent this from happening, just to keep the edit mode active regardless of the collapse state?
Thanks!
Adam
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:
Here's a detailed breakdown of the solution approach:
<igx-grid #grid [data]="data" height="650px" [primaryKey]="'ProductID'" [rowEditable]="true" (rowEditEnter)="rowEditStart($event)" (cellEditEnter)="cellEditStart($event)" (rowEditExit)="rowEditExit($event)" ></igx-grid>
public rowEditStart(event){ this.editedRowId = event.rowID; }
public cellEditStart(event){ this.editedColumn = event.column.field; }
<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; }
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
Thanks for your prompt and detailed response!
I'm having a bit of trouble putting this together - my first hurdle is that using this code:
Thank you for getting back to us, and I completely understand your decision. Sometimes, simplicity is the best approach, especially if it saves time and effort in the long run. It's great to hear that you found a workaround that meets your needs.
I'm glad if you found my responses helpful. If you have any more questions or need further assistance in the future, feel free to reach out.
Sorry for the delay in getting back. I have decided that what I'm trying to do isn't really supported by the grid, so I'll use a simple workaround where the columns will always expand on adding/editing - that way there's no way for the user to encounter this error. Thanks for all your help, if it was just editing it might have been feasible but like you say, it would be quite verbose and probably not worth it.
Thanks,
Hi Adam,
As my teammate Georgi is currently out of office I will assist you in the meantime.
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 PachilovaAssociate Software Developer
So I've implemented this solution (the issue with the click event not registering is there was some rogue css setting pointer-events to none for some reason) and it sort of works while editing. What it seems to do though is cancel all the edits that have been made to the row and just restart the editing process. So if the use has input a few bits of data in the cells, these are reset when expanding/collapsing.
The other issue (which was actually the main problem as this was where we noticed it first) is that if you add a new row, this solution throws an error as the cell seems to be undefined - maybe because it isn't part of the grid yet technically?
Let me know if you have any feedback on this.
Thank you for your prompt response and for providing additional details regarding your implementation of the collapsible column group within the tree-grid component. I appreciate your patience as we work through these challenges together.
I have been looking into your questions and:
Regarding the described behavior you encountered with the click event not firing on the igx-icon, I understand this can be frustrating. In the provided sample, the click event should indeed trigger the expandCollapse method. To troubleshoot this, I made some additional changes to observe the behavior more closely.
<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>
And the corresponding TypeScript method:
public expandCollapse(expanded) { console.log('Icon clicked.'); if (!expanded) { console.log('Column expanded.'); } else { console.log('Column collapsed.'); } this.isExpandOrCollapse = true; }
With these changes, you can now observe in the console whether the icon is clicked and whether the column is expanded or collapsed. Additionally, you can utilize the expanded parameter passed to the expandCollapse method to check if the column is expanded or collapsed for your custom implementation and logic in your project.
Regarding your further explanations about using a tree grid, it's important to note that the same principle outlined in the grid sample I provided also applies to the tree-grid component. While the functionality may differ slightly due to the hierarchical nature of the tree-grid, the underlying concept remains consistent.
Currently, the rowEditExit event cannot be stopped or canceled outright. However, it can be approached with the proposed solution. Here's how it works:
In summary, while the tree-grid component may introduce additional complexity due to its hierarchical nature, the same approach can be applied to maintain edit mode consistency and ensure a seamless user experience.
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.