На этом форуме параметр реестра HungAppTimeout ещё не обсуждался, хотя странно, это довольно важный параметр, благодаря которому можно повысить надежность ПО, которое многие из нас разрабатывают для коммерческого использования.
В нашем ПО есть следующая проблема: при запуске программы в основном потоке загружаются десятки DLL-библиотек, зачастую время их загрузки превышает 5 секунд. Это время зависит прежде всего от того, чем занят HDD (с SSD такой проблемы нет). Если HDD ничем не загружен, то библиотеки грузятся быстро (в 5 секунд вполне укладываются), но если HDD нагружен другими задачами, то DLL могут грузиться дольше в разы.
В том случае, если на экране открылось окно, а затем основной поток не успел выполнить свои задачи за 5 секунд, Windows вешает дополнительное окно с надписью "не отвечает". После того, как подвисание заканчивается, Windows убирает своё окно. Такие манипуляции с окнами в нашем случае приводят к тому, что иногда окно, с которым взаимодействует пользователь, улетает на задний план (не важно, в каком режиме оно было открыто: Show или ShowModal). В отдельный случаях пользователи даже умудряются закрыть окно, поверх которого открыто модальное окно, уехавшее на задний план (это может приводить к Access Violation). В случае терминала самообслуживания получается такой эффект: пользователь (водитель) видит служебное окно, а не то окно, которое рисуется для него.

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

Параметр HungAppTimeout содержит количество миллисекунд, является текстовым и живёт в разделе "HKEY_CURRENT_USER\Control Panel\Desktop". Применяется после перелогина. Работает по всех версиях Windows (проверял я его на 32-разрядных версиях).

Приму к сведению, спасибо!

если не лезть трогать его грязными руками.
Поставил его 10000. Это решило проблему. Думаю, лучше сделать 20000. Наше ПО зависает крайне редко, но небольшие подвисания возможны.

Вам известно, к каким проблемам это может привести?

автор
3. Недостаточно квалифицированные разработчики предпочитают решать проблему методом "кувалдой в лоб" вместо того, чтобы подумать.



Существует масса куда более важных вещей, о которых стоит подумать.

asviridenkovDmSer,

delayed загрузку DLL не предлагать?

Ваше дело предложить, наше ...
Приму к сведению!

softwarer
1. Инициализация приложения надолго грузит основной поток
2. Создаваемые окна получают неправильные настройки в результате чего возможно нарушение видимого порядка и следующие из этого артефакты поведения
3. Недостаточно квалифицированные разработчики предпочитают решать проблему методом "кувалдой в лоб" вместо того, чтобы подумать.

Отвечу ещё раз по пунктам.

1. Инициализация действительно надолго грузит основной поток. Это происходит, если программа находится в автозагрузке и используется HDD. В этом случае помимо нашего ПО параллельно грузится ещё масса других программ, что создаёт большую нагрузку на HDD. Плюс ещё и наше ПО при загрузке много чего пишет на диск.
2. Создаются VCL-окна с параметрами "по умолчанию". Никакими левыми настройками не увлекаемся.
3. Стараемся со своей стороны делать всё возможное, чтобы в основном потоке не выполнялось тяжёлых операций. Но работа с мелкими файлами и мелкие запросы к БД в основном потоке - в большом количестве, думаю, как и у всех Delphi-программистов. У программистов C# в этом случае преимущество, т.к. можно использовать механизм async/await.
4. Речь в этой ветке должна идти не об нашей программе. Если бы я горел желанием её обсуждать, то завёл бы другую ветку.

makhaonDmSer,

автор Инициализация действительно надолго грузит основной поток.
Может быть имеет смысл сделать инициализацию в доп потоке? пусть бы основной сообщениями занимался, как положено, проблем меньше будет.

Конечно, так было бы лучше, не спорю!

Грубые люди реагируют на такие реплики в духе "Командовать будешь своей женой"

Слава богу на этом форуме есть культурный человек, на которого всем нужно равняться =)

Вот что ещё удалось выяснить:
если создавать модальную форму таким образом: TMyForm.Create(nil), то при зависании (Sleep(20000)) после того как на ней появится "Не отвечает" можно будет щелкнуть на низлежащей форме и она окажется на переднем плане. Когда зависание кончится, модальное окно остаётся снизу.

Если же в конструктор передавать ссылку на форму, из которой открывается модальная форма, то вся цепочка модальных форм корректно восстанавливается после окончания зависания.

_Vasilisk_DmSerКогда зависание кончится, модальное окно остаётся снизу.Alt+Tab ее поднимет
DmSerЕсли же в конструктор передавать ссылку на форму, из которой открывается модальная форма,Достаточно передать Application

Мой тест показал, что передавать Application недостаточно. Глючит при этом реже, чем с nil. Но если передавать ссылку на форму, из которой выполняется вызов ShowModal, то сбоев вообще не возникает.