Диалог ожидания

[А.Н.]

Когда выполняется долгая операция, пользователю неплохо показывать, что программа ещё не сдохла.
Пытался сделать диалог ожидания с анимацией. Форма, на форме, TImage.
Картинки загружаются из ImageList и меняются через определённый интервал.

Проблема в том, что обычный таймер, в windows, не идёт (что, собственно, понятно, т.к. сообщения не обрабатываются). Поэтому приходится мудрить. Использовать такое, как "мультимедийный" таймер не хочется.
Пробовал сделать таймер в отдельном потоке. Но, обновлять приходится через Synchronize, иначе он выдаёт
ошибки. Естественно, что всё замирает, пока не выполнится ожидаемое действие.
Пробовал создавать форму в новом потоке. Ради интереса. Ругается по-чёрному. :-\
Application.ProcessMessages, естественно, не катит, поскольку, действием может быть, например выполнение запроса:

Код: Выделить всё

ShowWaiter();
Query.Open();
HideWaiter();

Поискал, подумал. Ничего не нашёл, голова не работает. Да и лениво.
Может, кто-нибудь знает как сделать? И... Может даже поделится?

[Odyssey]

Теоретически, надо бы делать Query.Open(); в отдельном потоке, т.е. писать наследника от TThread, внутри которого делать Query.Open(), а из основного потока запускать этот thread и по его завершении прятать диалог. Т.е. делать так,чтобы весь GUI оставался в основном потоке. К сожалению, проверенного, рабочего примера кода у меня нет, но тоже с удовольствием бы взглянул на такой пример.

[Timid]

Все неверно.
Нужно сделать расчет во вспомогательном потоке. А в основном выводить прогресс.
В крайнем случае вы оставите у себя возможность остановить расчет.

Примеров множество. Поищите компонент работы с потоками TThread, но лучше всего идти на delphikingdom.info и почитать там.

[А.Н.]

Да я понимаю, что нужно выполнять работу в отдельном потоке. По-идее, это правильно.
Но не знаю как будет Query, если результаты выводятся в DBGrid (поиск). Ведь, по-идее, он будет обновлять грид из другого потока без Synchronize... Но не знаю тут.
Дело-то в том, что у меня не расчёт. Именно выполнение запросов. Не знаю имеет ли особый смысл его останавливать... Сейчас всё, естественно, делается в единственном потоке, который и за GUI отвечает.
В принципе, меня это устраивает. Поэтому неплохо просто вынести форму в отдельный поток, например.
Даже просто - ради интереса. Ведь в другом процессе всё будет работать?
Как вариант - сделать отдельное приложение, выводящее диалог ожидания. Вариант очень некрасивый.
Не вариант. По-идее, неплохо просто обновлять форму, например, вызывая её метод, который использует
блокировку на время обновления.
Процесс, по крайней мере в виндавс, - просто контейнер потоков..? Т.е. в принципе, нет большой разницы, между потоком в текущем процессе и потоком в новом процессе?

Добавлено спустя 3 минуты 43 секунды:
А "Королевство" я знаю. Может, на delphi я бы ещё и написал такое... Не знаю.
Помнится я как-то тоже серьёзно накосячил с синхронизацией.
Но на Lazarus, вообще, как-то многое не так...

Чего ему мешает? Может, создать ещё один объект класса TApplication? o.O
Дикие мысли какие-то... Лучше никому не рассказывать.

[AbakAngelSoft]

delphikingdom.info

О! И как давно королевство перебралось на info? У меня в закладках ru, а раньше по моему был com. Проверил работаю все три варианта. :0

Ведь в другом процессе всё будет работать?

В другом потоке нет.
VCL в делфи и соответственно LCL в лазаре заточены под то что бы работать в одном потоке который считается основным потоком. Используется много глобальных переменных и т.д. Т.е. чтобы вынести форму в отдельный поток надо переписать весь LCL и часть FCL, а оно того не стоит.

Но на Lazarus, вообще, как-то многое не так...

Меня удивляет что наооборот в Lazarus почти все так-же, свой компилятор, сбои библиотеки, кросплатформенность в конце концов. Но вместо юниксового Fork испльзуется тот-же TThread! Это супер круто!

Может, создать ещё один объект класса TApplication?

Не поможет, глобальную переменную Application подменить только для одной формы все равно не получится.

[Timid]

Меня удивляет что наооборот в Lazarus почти все так-же, свой компилятор, сбои библиотеки, кросплатформенность в конце концов. Но вместо юниксового Fork испльзуется тот-же TThread! Это супер круто!

Форк в Windows потребует сделать обертку через критические секции, что-то придумать с памятью переменных и т.д. А объект - он все в себе держит

Но не знаю как будет Query, если результаты выводятся в DBGrid (поиск). Ведь, по-идее, он будет обновлять грид из другого потока без Synchronize... Но не знаю тут.
Дело-то в том, что у меня не расчёт. Именно выполнение запросов. Не знаю имеет ли особый смысл его останавливать... Сейчас всё, естественно, делается в единственном потоке, который и за GUI отвечает.
В принципе, меня это устраивает. Поэтому неплохо просто вынести форму в отдельный поток, например.
Даже просто - ради интереса. Ведь в другом процессе всё будет работать?
Как вариант - сделать отдельное приложение, выводящее диалог ожидания. Вариант очень некрасивый.
Не вариант. По-идее, неплохо просто обновлять форму, например, вызывая её метод, который использует
блокировку на время обновления.

Я понимаю, что буду выглядеть немного извращенцем, но я вообще не использую никакие гриды кроме DrawGrid.
А данные для него храню как динамический массив из записей (по структуре полей запроса).

Это развязывает мне руки - заполняю массив когда хочу (хоть из потока, хоть асинхронно), могу использовать критические секции, для обновления грида использую таймер (раз в 5 сек - оптимально).
onDrawCell - для вывода данных из массива в грид.

[Climber]

Да я понимаю, что нужно выполнять работу в отдельном потоке. По-идее, это правильно.
Но не знаю как будет Query, если результаты выводятся в DBGrid (поиск). Ведь, по-идее, он будет обновлять грид из другого потока без Synchronize... Но не знаю тут.

Может, так?

Код: Выделить всё

DBGrid.DataSource:=nil;
Query.Open;
DBGrid.DataSource:=MyDataSource;


Тогда, открывая датасет в отдельном потоке, мы никак не влияем на грид, который обрабатывается в основном. А когда данные уже загружены, подключаем грид обратно. Кстати, можно отключение/подключение в основном потоке сделать.

[dunin]

Может, так?

Код: Выделить всё

DBGrid.DataSource:=nil;
Query.Open;
DBGrid.DataSource:=MyDataSource;


Тогда, открывая датасет в отдельном потоке

Код: Выделить всё

DBGrid.DataSource:=nil;
Query.Open; // <------ и где тут отдельный поток?
DBGrid.DataSource:=MyDataSource;

[Climber]

Query.Open; // <------ и где тут отдельный поток?

А это домашнее задание Как отвязать грид от датасета, открыть датасет и привязать обратно в отдельном потоке Я только идею предложил...

[А.Н.]

сбои библиотеки

Хорошая опечатка.

кросплатформенность в конце концов.

Вот это, действительно, очень здорово. Причём, какая кроссплатформенность. Хорошо сделано.

Но вместо юниксового Fork испльзуется тот-же TThread! Это супер круто!

А что такого? Зачем делать fork()? Ведь, в любом случае, TThread - обёртка над API..?
А раз уж заявлена совместимость с Delphi... Кстати, тоже немаловажно. Хотя, совместимость и неполная, но,
как самодостаточная среда, Lazarus очень неплох. Особенно, учитывая то, что он бесплатный...

Не поможет, глобальную переменную Application подменить только для одной формы все равно не получится.

Не факт... Возможно, перед вызовом диалога, подменять Application, производить обновление в критической секции, затем снова его подменять на оригинальный... Хм... Мда, изврат.

Я понимаю, что буду выглядеть немного извращенцем, но я вообще не использую никакие гриды кроме DrawGrid.

Я так понимаю, что у вас, на базе DrawGrid, уже нехилая библиотечка самостоятельно написанных компонентов?

Это развязывает мне руки - заполняю массив когда хочу (хоть из потока, хоть асинхронно), могу использовать критические секции, для обновления грида использую таймер (раз в 5 сек - оптимально).
onDrawCell - для вывода данных из массива в грид.

С другой стороны, DBGrid уже написан разработчиками библиотеки... Да и OnDrawColumnCell тоже есть.
В принципе, ничто не мешает обновлять его и по таймеру...

Тогда, открывая датасет в отдельном потоке, мы никак не влияем на грид, который обрабатывается в основном. А когда данные уже загружены, подключаем грид обратно. Кстати, можно отключение/подключение в основном потоке сделать.

Уф, точно. Ведь ещё DisableControls есть. Да, я не подумал.
Эх, переписывать какие-то мрачноватые перспективы....

[AbakAngelSoft]

А что такого? Зачем делать fork()? Ведь, в любом случае, TThread - обёртка над API..?

Я именно про это и говорю. Очень удобно писать код не задумываясь на какой платформе он будет работать, а занимаясь только своей работой. Написал потомка TThread и в windows и в linux с точки зрения программы он будет себя вести одинаково.