Блог. Двадцать пять лет Делфи-практики
В этом блоге я буду публиковать ответы на вопросы, которые постоянно приходится повторять на форуме.
Здесь можно это сделать более развернуто и спокойно.
Все, что здесь написано, не является истиной в последней инстанции, скорее, это результат моих размышлений над архитектурой проектов, маленьких и больших, которых я сделал на Делфи более дюжины.
Начав с Делфи-2 двадцать пять лет назад, я прошел все версии, испробовал массу технологий, включая работу с БД, с графикой DirectX, связью с серверами и интернетом, разработку на Андроид и IOS, и многое, многое другое.
________________________________________________________________________________ ____
P.S. все, о чем здесь написано, всего лишь измышления из головы.
совпадения с реальными людьми и фактами случайны.
В этом блоге я буду публиковать ответы на вопросы, которые постоянно приходится повторять на форуме.
Здесь можно это сделать более развернуто и спокойно.
Все, что здесь написано, не является истиной в последней инстанции, скорее, это результат моих размышлений над архитектурой проектов, маленьких и больших, которых я сделал на Делфи более дюжины.
Начав с Делфи-2 двадцать пять лет назад, я прошел все версии, испробовал массу технологий, включая работу с БД, с графикой DirectX, связью с серверами и интернетом, разработку на Андроид и IOS, и многое, многое другое.
________________________________________________________________________________ ____
P.S. все, о чем здесь написано, всего лишь измышления из головы.
совпадения с реальными людьми и фактами случайны.
Индикатор загрузки
| Встречаются два вида долгих операций Прогресс одних мы знаем и можем вывести в процентах. Например, состояние расчета или скачивание большого файла. Другие операции неизвестно сколько времени займут, а иногда и вообще неизвестно, закончатся ли. При проектировании интерфейса нужно запомнить одно Сама операция должна быть вынесена в отдельный поток. А индикатор должен крутиться в главном. Общая идея 1. Стартовать индикатор (открыть форму, сделать активной анимацию или еще что-то в этом духе) 2. Создать класс потока 3. Если у потока есть прогресс, то дать потоку ссылку на обработчик прогресса 4. Дать потоку ссылку на обработчик окончания потока 5. Запустить поток подробнее о потоках - тут https://www.cyberforum.ru/blog... g4875.html Если мы хотим сделать таймаут, то можно воспользоваться простым таймером на N мсек В классе потока предусмотреть флажок Актуальный. Если происходит выход по OnTerminate, проверять, если поток НЕ актуальный, просто ничего не делать. Он убьет себя сам. (в статье выше предлагается использование FreeOnTerminate потоков) Если поток актуальный, то нужно не забыть остановить таймер. Если таймер сработает, значит, его не отключали и нужно сделать поток НЕ Актуальным. Возможно в этот момент нужно сообщить пользователю про таймаут и спросить, не хочет ли он попробовать еще раз. |
Всего комментариев 4
Комментарии
-
Зачем? В идеале код должен быть построен так, чтобы одна операция не занимала слишком много времени. Если это выполнение запроса по закачке данных из БД, то БД должна быть нормализована, а количество стягиваемых данных за приём не должно превосходить пропускную способность подключения к БД.Цитата:Сама операция должна быть вынесена в отдельный поток. А индикатор должен крутиться в главном.
Так зачем же операцию в отдельный поток?
P.S. Мне просто интересно, ибо не пока не читал об этом в литературе.Запись от Matan! размещена 16.08.2018 в 11:59 
-
Вот за этим, например:
Цитата:скачивание большого файлаСколь ни оптимизируй БД, всё равно можно получить время выполнения операции дольше, чем несколько мс, и при выполнении такой операции в потоке GUI этот самый GUI подвиснет.Цитата:Если это выполнение запроса по закачке данных из БД,Запись от Rius размещена 16.08.2018 в 12:04
-
совершенно верноЗапись от krapotkin размещена 16.08.2018 в 21:20
-
Если пользователь работает с одними и теми же данными, то почему бы их не качнуть все сразу закешировать и не нагружать сеть и БД сразу?Цитата:Зачем? В идеале код должен быть построен так, чтобы одна операция не занимала слишком много времени. Если это выполнение запроса по закачке данных из БД, то БД должна быть нормализована, а количество стягиваемых данных за приём не должно превосходить пропускную способность подключения к БД.
Так зачем же операцию в отдельный поток?
P.S. Мне просто интересно, ибо не пока не читал об этом в литературе.
Естественно если это позволяет логика ибо это специфичный случай.
Как правило это не надо и по логике это не верно.
Например нет смысла качать 10000 записей из БД, можно качать страницами по 100 по мере надобности, по запросу пользователя.Запись от Avazart размещена 16.08.2018 в 22:47
Обновил(-а) Avazart 16.08.2018 в 22:49
