Мне рекомендуют писать баги Вам. Дублирую информацию.
Я нашёл реальный БАГ в EhLib 6.3 Build 6.3.181. Он проявляется только когда таблица в гридине пустая. Связываю таблицу с любым датасетом - для примера я взял FireDAC с драйвером FireBird. В гридине видна одна псевдострока для первой вставки. Выбираю поле NAME и тыкаю в него мышкой. - Открывается InplaceEdit для режима редактирования, но состояние датасета ещё не изменилось - он не перешел в режим вставки. До этого момента всё правильно. Теперь нажимаем букву "G". Датасет переходит в режим dsInsert и InplaceEdit закрывается без вставленной буквы G. Такого раньше не было!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! Если в датасете есть хоть одна запись, на новую запись мы попадаем либо стрелкой вниз в гридине либо плюсиком, но попадаем туда уже в режиме вставки.
Подробности бага.
Как мы будем ловить багу? Очень просто - ставим брейкпоинт на GridEh.pas внутрь метода TCustomGridEh.HideEdit. Теперь так же делаем G и смотрим стек отладки. По стеку мы видим что датасет шлёт событие что он datasetChanged из метода Insert, что вполне справедливо. Далее TCustomDBGridEh.InternalLayout пытается вызвать метод UpdateFilterEdit(True), что справедливо, но мы же не в режиме фильтрации? Далее вызывается метод TCustomDBGridEh.StopEditFilter, что подозрительно - мы же не в фильтрации... Однако он безапелляционно вызывает :
Код:
Код:
procedure TCustomDBGridEh.UpdateEditorMode;
begin
if (dgAlwaysShowEditor in Options) and
not FilterEditMode and
not (csDestroying in ComponentState)
then
ShowEditor
else
HideEditor;
end;
В нашем случае dgAlwaysShowEditor не установлен, так как хоть он и работает, но не очень красиво. А так как он не установлен - любые другие условия не влияют и происходит HideEditor. Тут либо косяк в StopEditFilter - так как мы не в режиме фильтрации, либо косяк в UpdateEditorMode.
Добавлено:
Хотя уже EhLib 7 вышла, но там тоже может быть эта бага. Проверьте плиз интересно...