Hello Microsoft Add-in team! I'm developing an Excel Add-In and have some suggestions relating to Excel.ErrorCodes.invalidOperationInCellEditMode.
I'm finding that having the Excel Add-In APIs all either delay execution or throw the CellEditMode error while the user is in cell edit mode is making for a bad user experience in my Add-in. For example, at launch, my Add-In TaskPane needs to check the workbook CustomXML for metadata specific to my Add-In. But (if I'm not mistaken) I can't do that if the user is in cell edit mode. It seems I have to call the API, get a failure, then tell the user something like "The Add-In is waiting for you to finish editing your cell" and try again with { delayForCellEdit: true }. It's messy.
So my suggestions are three, supposing CellEdit errors are in some cases necessary:
1.) Can we make it so that not *every* API call is blocked when in CellEdit mode? For example, why should reading/writing CustomXML be blocked because of cell editing? Is the error being thrown unnecessarily in some cases?
2.) Can we add a new "addHandlerAsync" event for CellEditMode enter/exit, to allow a TaskPane to disable buttons that aren't going to work while the user is in CellEdit mode? Disabling such buttons (with explanation, of course) could make for a better TaskPane user experience than having the user clicking a button and getting an error. (I do realize the error could still happen, as change events seem to fire on a delay, but they might at least happen less frequently!) (For example, in my Word Add-In, I am enabling/disabling buttons based on user's content selection, and the experience seems to be nice, even with the slight delay.)
3.) Can we add another callback param to "Excel.run({ delayForCellEdit: true }, ...)" so the developer can know that their API calls will be delayed and the user can be prompted to exit CellEditMode? (That might clean up me having to try, catch and then retry with delay?)
