Dimitry Sibiryakov, когда сами MS исправят свой Excel (у меня 365) так, что при открытии больших-больших файлов в шапке не показывается "(не отвечает)", тогда и я поправлю))))

Совет хороший и правильный. Учту!

Dimitry Sibiryakov, полностью поддерживаю - Excel'ю 30 лет, а никак в отдельный потом загрузку не вынесут. И пресловутую ошибку с _FilterDatabase до сих пор не исправят, и не сделают штатную возможность выставления ширины колонок в миллиметрах...

Но также интересно, неужели в программах Дмитрия Сибирякова весь ввод/вывод вынесен в отдельный поток? И даже из файлов чтение в отдельном потоке (там тоже может подвиснуть внешнее устройство)? И с БД работа вся асинхронная?

Dimitry Sibiryakov, у меня нет оснований тебе не верить.

Я, конечно, "закис" в своем приложении, когда сервер с локальной гигабитной сети. И мелочь при обращении к серверу поточить смысла просто нет. Отчеты вот надо отпоточить. В планах стоит.

Интересно, что у тебя за приложение, в котором тотальное асинхронное общение с БД? Что за тип приложения? Чем технически это делаешь? Своя библиотека или штатными средствами Delphi пользуешься? Расскажи, плз, интересно же. Первый раз встречаю приложение на Delphi с полностью асинхронным взаимодействием с БД.

Dimitry SibiryakovDimitry TimokhovЧем технически это делаешь?

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

А когда выполняешь любую процедуру (БД?) в фоне, чем к БД коннектишься?
И интересно, как прогресс определяешь?

Dimitry SibiryakovDimitry TimokhovА когда выполняешь любую процедуру (БД?) в фоне, чем к БД коннектишься?

Используется основной (единственный) коннект. Прогресс - по этапам обработки.

Ок. Понятно. Всё логично.

У меня тоже есть некоторые долгие запросы к БД в доп. потоке. Использую ADO, синхронно. Сам импортировал OLE либу (т.е. стандартными компонентами не пользуюсь). Даже, если бы пользовался асинхроном ADO, то там все равно нет А) прогресса и Б) не прервешь (я не нашел). Т.к. ADO по определению имеет потоковую модель apartment, а не multithreaded, то долгие запросы делаю в отдельном коннекте, т.к. не могу использовать один ADODB.Connection из двух потоков.

Критично то, что замирание на 5+ сек есть во встроенном скриптовом языке. На это я повлиять не могу. Пишут прикладные разработчики. Там есть и GUI и вычисления... Там уж не распоточишь это дело легко.

Собственно, поэтому и влез в топик. Чтобы понять и разобраться с режимом Ghost, в который Windows принудительно переводит любое приложение через 5 сек, если то не вызывает PeekMessage или аналоги.

Василий 2Dimitry TimokhovЧтобы понять и разобраться с режимом Ghost, в который Windows принудительно переводит любое приложение через 5 сек, если то не вызывает PeekMessage или аналоги.
Собственно, если проверяется просто вызов Peek/GetMessage, то запуск фонового потока, создающего невидимое окно и таймер и крутящего цикл выборки сообщений, решит проблему "призракизации". А если это окно будет видимо, и будет показывать симпатичную анимашку или просто прогресс-бар, так совсем хорошо

Погоди))

Правильно я понимаю, что ты говоришь о том, можно PeekMessage делать в доп. потоке для окна, созданного средствами WinAPI в этом потоке, и этого будет достаточно, чтобы Windows не перевел *все* приложение в режим ghost?

Иными словами, ты считаешь, что достаточно делать PeekMessage в *любом* потоке процесса, а не обязательно в главном (первом) потоке?

softwarerА смысл? Ну то есть вот есть некий запрос, который открывается десять секунд. В чём преимущество открывать его в фоне, закрыв модальным окном, по сравнению с crSQLWait в основном потоке?
Не мне, но предположу.
Так все равно же в "(не отвечает)" впадает главная форма.

kealon(Ruslan),
Василий 2,

В общем проверил:
1. Создал окно на WinAPI (выбрал из другого своего проекта). Оно живое, обрабатывает очередь. Даже перерисовывается.
2. Все равно - через 5 сек в главном окне появляется "(не отвечает)".

Вывод - Windows анализирует очередь главного (первого) потока. А не всех, которые принадлежат процессу.

Василий 2Dimitry Timokhovkealon(Ruslan),
Василий 2,

В общем проверил:
1. Создал окно на WinAPI (выбрал из другого своего проекта). Оно живое, обрабатывает очередь. Даже перерисовывается.
2. Все равно - через 5 сек в главном окне появляется "(не отвечает)".

Вывод - Windows анализирует очередь главного (первого) потока. А не всех, которые принадлежат процессу.
Любопытно, хотя и странно. Какое дело Винде, какой там из потоков главный...

Чем больше думаю про эти ghost-окна, тем больше понимаю, что сделано в Windows все логично.
Будь у приложения 1000 потоков, Винда "ляжет" в цикле проверять их все.
Поэтому проверяет только очередь основного потока и порожденные им окна.

Видимо предполагается, что основной поток <=> главное окно.

Хотя Windows могли бы лучше это все задокументировать. ИМХО.

kealon(Ruslan)Василий 2пропущено...

Любопытно, хотя и странно. Какое дело Винде, какой там из потоков главный...тогда скорее всего проверяются все главные окна
через SendMessageTimeOut, это логично бы было

Вот и я про то же - могли бы лучше описать. Я лично не нашел чего-то внятного. Только пояснения на форумах и минимум текста в описании MSDN по теме...

И шикарная фраза "[This function is not intended for general use. It may be altered or unavailable in subsequent versions of Windows.]" тут https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-ishungappwindow...

Видимо, думают, а не "сносить" ли такие приложения сразу в Windows 11+?)))

Хотя все это не важно - ghost в любом случае лучше, чем без него.
Т.е. если вызвать DisableProcessWindowsGhosting, то вообще все мрет. А с гостом хоть отрисовывается и показывает, что "(не отвечает)". Т.е. имитация жизни))) И дает надежду, что отомрет.