GetWindowThreadProcessId()

← →
VMcL © (2004-02-09 15:23) [0]

Дано:
- некая программа, пользующая глобальный хук на клавиатуру и мышь;
- некая процедура в этой программе (не в DLL), которая вызывает subj.

Обнаружено, что:
- при исполнении программы под Delphi IDE отладчиком при включенных хуках, выполнение subj приводит к повису ОС; "отвиснуть" ОС можно только с помощью {Ctrl+Alt+Del + Log Off} или {Alt+Tab на Far + Список Процессов + погасить (F8) delphi32.exe};
- при исполнении программы не под Delphi IDE отладчиком или в случае, если хуки отключены, вызов subj проходит нормально и возвращает корректное значение.

Вопрос
Почему вызов subj приводит к зависанию? Ведь subj вроде как не посылает сообщений по типу SendMessage().

P.S. Промежуточное решение реализовано так:
if not IsDebuggerPresent() then GetWindowThreadProcessId(...)
но это не есть хорошо, во время отладки программа частично теряет функциональность.

← →
Игорь Шевченко © (2004-02-09 15:44) [1]

Первый вопрос: Окна своего процесса опрашиваются или потенциально любого ?

← →
VMcL © (2004-02-09 15:46) [2]

>потенциально любого

← →
VMcL © (2004-02-09 15:51) [3]

>[1]+[2]
В том числе и окна delphi32.exe.

← →
Игорь Шевченко © (2004-02-09 15:57) [4]

subj вызывает блокировку диспетчера Win32 на время выполнения запроса, внутри самой реализации NtQueryWindow вроде, ничего, приводящего к зависанию нету - получение нужного потока/процесса.

Еще вопрос: как известно, в Subj можно указать получение только ID потока, задав параметр ProcessID равный 0. Будет ли программа зависать и в этом случае ?

← →
VMcL © (2004-02-09 16:12) [5]

>>[4]

Исходники дома. Приду проверю. Thanx.

← →
VMcL © (2004-02-09 20:57) [6]

>>Игорь Шевченко © (09.02.04 15:57) [4]

GetWindowThreadProcessId(AWnd, nil);
Не зависает, но мне это не очень нравится, так как нужен именно Process ID :((

Вижу следующее изощрение:
1. Получить всё-таки не Process ID, а Thread ID.
2. CreateToolhelp32Snapshot + Thread32First + Thread32Next => находим Thread => THREADENTRY32.th32OwnerProcessID

Но я так не хочу, извращением попахивает :)

← →
Игорь Шевченко © (2004-02-10 12:05) [7]

Если тебе надо только в Win2k, то NtQuerySystemInformation вместо ToolHelp, пример в http://www.schevchenko.net.ru/SRC/QuerySystemInformation_60.zip

← →
Игорь Шевченко © (2004-02-10 12:06) [8]

Кстати, иначе не получится, так как ThreadID не уникальный в системе, а уникальный внутри процесса.

← →
Владислав © (2004-02-10 17:45) [9]

Это из Platform SDK:

Until the thread terminates, the thread identifier uniquely identifies the thread throughout the system.

← →
Игорь Шевченко © (2004-02-10 18:18) [10]

Владислав © (10.02.04 17:45)

Упс. Спасибо, я похоже, с Handle спутал...

← →
Владислав © (2004-02-10 18:31) [11]

Игорь Шевченко © (10.02.04 18:18) [10]

Бывает, но с другой стороны нельзя забывать ключевые слова: "Until the thread terminates" ;)

← →
Игорь Шевченко © (2004-02-10 19:07) [12]

> : "Until the thread terminates"

Тогда и окон не будет. См. сабж.

← →
Владислав © (2004-02-10 19:38) [13]

Бесспорно.

>>Игорь Шевченко © (10.02.04 12:05) [7]

Ну проблема вобщем-то только при отладке. А отлаживаю я под Win2K. Так что могу тогда оставить проверку IsDebuggerPresent(), но в случае присутствия отладчика не пропускать получение Process ID, а получать его с помощью [6] или [7].

Отдельное спасибо Игорю Шевченко, надо будет не забыть упомянуть его в своей программе :)

95 не рассматривается?..

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

Проблема решена посредством [6].

P.S. Напоролся на еще одни грабли a-la subj: GetModuleFileNameEx. Но обошел их.

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

Готово. Благодарности Игорю Шевченко впечатаны в About ;)

GetWindowThreadProcessId() Найти похожие ветки