Если вы не делаете некие операции с формой на OnCreate или на OnShow, значит, в эти моменты вам чего-то не хватает. Нужно понять, чего именно не хватает, и в какой момент будет хватать. От этого зависит и метод "обхода".

Что-то полезное происходит при обработке следующих, уже стоящих в очереди событий? PostMessage отправит вас в конец очереди, когда она к вам подойдет, почва уже будет подготовлена. Вместо PostMessage можно прокрутить очередь через Application.ProcessMessages, но это плохой способ. Однако, если должна пройти цепочка событий, каждое из которых вызывает следующее через постановку в очередь сообщений, такой метод будет бесполезен.

Что-то полезное приходит извне, и надо только его дождаться? Тогда таймер, как показали выше. Интересно, как вы будете определять задержку таймера, экспериментально?

Зачем запускать параллельный поток, который должен будет дергать визуальные компоненты из основного, лично мне непонятно. И, главное, что именно тот поток будет ждать, чтобы выполнить свою работу? Если по времени, то для этого и обычного таймера достаточно.

А... Ну тогда, если загрузка длительна, PostMessage мало поможет, разве что перед "заморозкой" кнопки прорисуются, все равно неприятно.

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

Дельфин - это хорошо :)

Можно влезть с ProcessMessages в Query.OnRow или Query.OnFetch, что там у них есть, но это уже перебор, пожалуй.

Умолчально, по задумке создателей инструмента, сценарий делфи-приложения таков:

1. Все, что нужно и можно, грузится на OnCreate (откуда вы взяли OnShow? Show и Hide случаются в другие моменты, не надо лишний раз ничего трогать). Форма в это время не видна, пользователь ищет её на лужайке Майкрософта, но не находит.

2. Потом случается Show, и форма, полностью загруженная и прекрасная, окрывается взору.

Такая задумка. Если шаг 1 стараниями программиста стал невозможно долог, перед ним запускают другую форму попроще, с логотипом, например "Borland", чтобы как-то успокоить отчаявшегося уже было пользователя и отвлечь от лужайки. Не бог весть что, но лучше пустышки с кнопкой "Приступить к работе".

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

Конечно, можно. Мысли и руку создателей можно увидеть в папке samples, прилагаемой к среде, в частности, в подпапке delphi\database и др. Там все начальное наполнение форм, если таковое случается, происходит на FormCreate. Более того, уверен, что такое использование рисуется в различных учебниках и Getting Started от создателей и третьих лиц, но, ей-богу, лениво искать, прошу простить. Если это не так, готов съесть свою панамку.

Конечно, для начинающих. Продолжающие пишут на базовых инструментах свои фреймворки и играют в них по своим правилам. А совсем просветленные ничего не пишут, они управляют потоками силою мысли.