как получить данные в дбгрид, так чтобы они при загрузке программы отображались сразу

Если компоненты доступа к данным находятся на отдельном TDataModule, то в событии OnCreate главной формы, иначе в onShow: Открыть базу и датасет.
Привязка DBGrid -> DataSource -> DataSet

>Sirus   (16.06.09 08:04) [1]
>Если компоненты доступа к данным находятся на отдельном TDataModule, то в событии >OnCreate главной формы, иначе в onShow: Открыть базу и датасет.

Датамодуль тут не играет рояли
Если в событии OnShow, то будет эффект "белых" окон.
Предпочтительнее в OnActivate с флажком.
Например,

procedure TForm1.FormActivate..
begin
  if Tag=0 then
      ... Открытие датасета
  Tag := 0;
end;
end;

> Предпочтительнее в OnActivate с флажком.


Это очень спорный вопрос, что тут предпочтительнее.
Лично я такие вещи в OnCreate ставлю. Либо в инициализации фрейма (последнее время на фреймах GUI предпочитаю строить). Но точно не на OnFormShow или OnFormActivate

Угу, и при запуске проги юзер наблюдает скатерть или фрагменты будущего окна :)
Особенно если нет соединения или запрос выполняется достаточно долго.

> Угу, и при запуске проги юзер наблюдает скатерть или фрагменты
> будущего окна :)


У меня не наблюдает. Что я делаю не так?

> У меня не наблюдает. Что я делаю не так?

Не пишешь запросы, которые работают по 5-16 часов.
Я пишу, посему у меня всегда кнопочка "обновить" прицеплена.
:)

> Я пишу, посему у меня всегда кнопочка "обновить" прицеплена.


Блин, ну ты же не цепляешь их на FormCreate :)

> Не пишешь запросы, которые работают по 5-16 часов.
если открывать такой в OnCreate то это приведет только к тому, что форма откроется через 5-16 часов с полностью заполненным гридом.
никаких "скатертей или фрагментов будущего окна" не будет.

>никаких "скатертей или фрагментов будущего окна" не будет.

Смотря какие компоненты доступа и как используются

есть компоненты которые умудряются рисовать на форме при отсутствии оной?
чудесные наверное компоненты. Хотабыч делал.

Рисуют, конечно, не компоненты. Они просто дают "дышать" основному потоку :)

> Они просто дают "дышать" основному потоку :)
ну и что? создание не завершилось, следующих за ним событий типа шоу/активейта не будет.

проверь, накидай сделай кучу компонент себе на форму и пропиши код в онгрейт типа




можешь поставить там не 100 а 1000 например, и жди до посинения.

для показательности можеш еще вот это добавить

> можешь поставить там не 100 а 1000 например, и жди до посинения.


1000 для посинения мало, бери 100000.

У меня DBGrid привязан к DataSource.
DataSource правда привязан к Table
И если TableName указан прямо и свойство Active=True, то при открытии окна сразу все видно.
Так же, как и в дизайн-тайм.

ЗЫ: Правда программа маленькая и использует только одну таблицу.

Я при длинных запросах делаю так:

const
 UM_RETRIEVEDATA = WM_APP+666;

type
 TfFoo = class(TForm)
   procedure FormShow(Sender: TObject);
  procedure FormCreate(Sender: TObject);
 strict private
   procedure UmRetrieveData (var Message: TMessage); message UM_RETRIEVEDATA;
 end;

procedure TfFoo.FormCreate(Sender: TObject);
begin
 ...
 панельзаставки.BoundsRect := контролсданными.BoundsRect;
 панельзаставки.BringToFront;
end;

procedure TfFoo.FormShow(Sender: TObject);
begin
 PostMessage(Handle, UM_RETRIEVEDATA, 0, 0);
end;

procedure TfFoo.UmRetrieveData(var Message: TMessage);
begin
 Update;
 Application.ProcessMessages;
 Screen.Cursor := crSQLWait;
 try
   открыть запрос с данными;
 finally
   Screen.Cursor := crDefault;
 end;
 контролсданными.BringToFront;
end;

на месте того контрола, где показываются данные запроса, помещаю панельзаставки с заголовоком "fetching data, please wait"

> Игорь Шевченко ©   (16.06.09 15:03) [16]


Интересный вариант. Возьму на заметку.

Ega23 ©   (17.06.09 12:54) [17]

Как альтернатива - выполнять запрос в отдельном потоке (тоже, кстати, работает), но кода писать больше.

> Как альтернатива - выполнять запрос в отдельном потоке (тоже,
>  кстати, работает), но кода писать больше.


Не, отдельный поток - это не для нас. :)
На самом деле довольно слабо могу себе представить клиента под БД, который запросы в отдельном потоке фигачит. Ну разве что, когда быкап делает.

> На самом деле довольно слабо могу себе представить клиента
> под БД, который запросы в отдельном потоке фигачит


Э...у меня полно таких случаев. Например, на главной странице проекта настроить графиков по текущему состоянию, или показать какие-то события, которые могут подтолкнуть пользователя на какие-то действия, а могут и не подтолкнуть. Суть в чем - если пользователь уходит с главной страницы, то потоки благополучно заполняют себе промежуточные dataset'ы, благо небольшие, захочет - обратно вернется и увидит данные, не захочет, выберет другие задачи - ну что же, не сложилось. Заставлять его ждать, пока не выберутся все данные негуманно - может, он программу с другой целью открыл ? Разумеется, это все настраивается, можно отказаться от таких запросов, но выглядит симпатично.

> Разумеется, это все настраивается, можно отказаться от таких
> запросов, но выглядит симпатично.


Да не, я не спорю. Если это аналитика и рекордсеты приходят действительно небольшие (а вот сами запросы - очень тяжёлые), то пуркуа бы и не па.
У меня, просто, несколько другой срез задач.

> можешь поставить там не 100 а 1000 например, и жди до посинения.

За 50 секунд не успеет остыть.

Удалено модератором

Удалено модератором

Удалено модератором