Подводные камни автоматизации My Visual Database

Вообще тема не совсем удачно наречена...
Это не "подводные камни автоматизации в MVDb", а "особенности строения последовательности процедур в [любом] однопоточном приложении".

Визуально-приятное решение вопроса:

1). Таймер (с запросом при первой итерации).
2). Открытие формы
3). Запрос. Отключение таймера.

Пример реализации типа: "теперь ты сверху, а я снизу".

P.S. Я хз, в каком потоке работает таймер, но в ряде случаев выручает там, где курит Application.ProcessMessages.
P.P.S. Если нужно выполнить несколько "тяжелых" процедур (которые одной итерации могут создать одну "ультра-тяжелую") - можно разбить их по нескольким итерациям и всунуть между ними Application.ProcessMessages для внутреннего душевного успокоения (что прога работает, а не повисла нафик).

Многопоточность, как мне показалось, в MVD местами имеется. Например, при отрисовке таблиц и деревьев.

Пример с асинхронным выполнением запроса к БД и отображения формы будет давать эффект, если форма не просто открывается, а создается. В MVD все формы создаются до подключения к БД и открываются шустро. С другой стороны, если форма открылась, а запрос тяжёлый и тупит, то разглядывание формы без данных - скучное занятие )))

На самом деле идея с таймером классная: так как в MVD нет события OnAfterShow, то вместо него можно использовать таймер: после отображения формы с таблицей запускается таймер (10 мс,) в котором вызывается клик по кнопке обновления данных на форме. И пользователю будет понятно, над чем именно "думает" в данный момент программа. Разумеется, проблема однопоточности выполнения самих скриптов останется...

А в моём примере проблема не в кривом запросе (его ведь сделал пользователь - вот пусть и думает над своим поведением), а в том, что при открытии формы туда тянется то, что там не нужно. Но я согласен со sparrow - это небольшая плата за автоматизацию. И она сможет стать ещё меньше, если у формы добавить свойство dbSQL, в котором будет храниться запрос на открытие формы редактирования и который можно будет ручками тюнить.

2. Автообновление табличного представления после редактирования

Как вы знаете, после редактирования, добавления или удаления записи происходит обновление табличного представления на форме, из которой был осуществлен вызов формы редактирования. В большинстве случаев это очень удобно и логично: изменения сразу видны без лишних движений. Однако при большом числе записей это становится не очень удобным, так как обновление производится через полное обновление данных: новый запрос и перестройка визуального компонента.

Тут явно напрашивается оптимизация - при удалении записи можно удалить только одну строчку из табличного представления, а при редактировании - обновить одну строчку в табличном представлении. При добавлении универсального алгоритма определения, в какое именно место нужно добавить новую строчку нет, но, как мне кажется, добавлять можно в конец, главное на неё фокус передать. Хотя можно определить, по какому полю сейчас осуществляется сортировка и найти точное место для вставки добавленной строки.

В настоящий момент такую оптимизацию можно сделать вручную через скрипты только в случае, если таблица заполняется через SQL-запрос, так как только в этом случае не срабатывает автоматическое обновление табличного представления. Но лучше, если такая возможность была бы встроена, например, как опция в свойствах табличного представления.