Логично
Интересно, а нормальное решение есть? Без имитации клавиатурного ввода?
Ведь такая имитация плоха уже тем, что при этом отменяются внесенные юзверем в ячейку изменения. Сравните это с поведением самого Excel: если мы пытаемся его закрыть в момент редактирования, внесенные в ячейку изменения считаются подтвержденными.
Кстати, напомню, что в ряде случаев такая блокировка со стороны Excel очень логична (если, например, юзверь сидит в диалоговом окне).

Во многих случаях может подойти открытие данных как внедренного OLE-объекта. При этом как только пользователь переключится на другой элемент нашего окна, automation закроет эксель (в т.ч. если эксель был в режиме редактирования — но не в диалоговом окне). Правда, есть и досадный глюк (по кр. мере, в D6): если в design-time открыть (open, а не edit) объект в OLEContainer, а потом закрыть только книгу (но не эксель), будет закрыта и эксель тоже. А вот если то же проделать в рантайме — эксель останется открыта. Подробно не смотрел — может, как-то это регулируется. Ну сопровождение этого глюка — если один раз объект открыли в режиме open и закрыли, потом с ним можно делать что угодно — но в режиме просмотра в контейнере он при этом будет заштрихован серым (как если в данный момент редактируется в режиме open).

На выбор еще три варианта, не полностью, но решающих проблему: 1) ждем, пока Excel не согласна будет выполнить нашу команду (юзер покинет диалог или выйдет из режима редактирования), 2) блокируем пользовательский интерфейс Excel, 3) открываем данные в режиме "только для чтения" (проблема с диалогами остается).

Кстати, а зачем понадобилось показывать юзеру эксель и разрешать редактирование? И почему убивать Excel мы пытаемся из нашего приложения? Раз уж юзеру дали возможность полазить по таблице, так может, он сам определится, когда ему выходить?

Slicer