КОРРЕКТНО завершить чужой процесс

[alibek]

Ты не знаешь, что WM_?

[SLIM]

Вот ты!!!
Есть окно, у окна есть WinProc, который обрабатывает сообщения.
WinProc вызывает Disp.Mess. в цикле обработки сообщений. Если окна не видно, не значит что его нет.

Окно привязано к к какому-то потоку. Где-то в недрах WinProc стоит обработка сообщений WM_, где-то в ней (в обработке сообщения) написано что будет завершаться поток\процесс. WinProc привязан к окну, а не к потоку.

UPD:
Окон соответственно не всегда столько, сколько потоков. Это раз
WM_ - это Window Message, даже по названию понятно все

[Space]

ну и что? Я перебираю потоки, шлю им WM_QUIT и проги спокойно завершаются. Я использую эту фишку для таких простых прог без окон, которые я раньше писал на Асме и пишут другие люди. Мне просто интересно, нормально ли будут завершаться проги с окнами по этому же методу, т.е. завершаться вообще без подвисов. Как показал тест, нормально. Я не знаю точную схему обработки сообщений на отрезке ПРОЦЕСС-ПОТОКИ-ОКНА, поэтому и интересуюсь.

[Space]

Я просто думал, что посыл WM_QUIT по окнам приведёт к Unload Form, что будет несколько более корректным завершением, чем посыл WM_QUIT по потокам, однако, как показал тест, Блокнот завершается при получении WM_QUIT и наличии диалогового окна о сохранении данных с потерей данных. Поэтому я пока остановился на более универсальной процедуре посыла WM_QUIT потокам. Мне просто нужно 100% завершить прогу, но наиболее корректно.

[SLIM]

ну и что? Я перебираю потоки, шлю им WM_QUIT и проги спокойно завершаются. Я использую эту фишку для таких простых прог без окон, которые я раньше писал на Асме и пишут другие люди. Мне просто интересно, нормально ли будут завершаться проги с окнами по этому же методу, т.е. завершаться вообще без подвисов. Как показал тест, нормально. Я не знаю точную схему обработки сообщений на отрезке ПРОЦЕСС-ПОТОКИ-ОКНА, поэтому и интересуюсь.

Ты прикалываешься? Я не знаю что ты там конкретно писал на асме, но у тебя явно неправильное понимание вопроса, раз ты так рассуждаешь.
Вот к примеру есть ф-я CreateThread - создает поток. Никакого нафиг окна она не создает.

Я просто думал, что посыл WM_QUIT по окнам приведёт к Unload Form, что будет несколько более корректным завершением, чем посыл WM_QUIT по потокам, однако, как показал тест, Блокнот завершается при получении WM_QUIT и наличии диалогового окна о сохранении данных с потерей данных. Поэтому я пока остановился на более универсальной процедуре посыла WM_QUIT потокам. Мне просто нужно 100% завершить прогу, но наиболее корректно.

Ну это уже...
Unload Form не существует впринципе. Ты понимаешь что...хотя что тебе объяснять.
Хочешь я тебе накатаю приложение, которое ты не закроешь WM_QUIT?

[Space]

я и сам могу такое накатать. Только зачем? Все нормальные приложения "понимают" WM_QUIT
может, WM_QUIT не приведёт к Form_QueryUnload, я не спорю. Сейчас проверим.
SLIM, это ты не понимаешь, что WM_QUIT существует не исключительно для окон. Оно попадает в процедуру обработки сообщений, и его обработка уже зависит от кода программера.

[SLIM]

Вот слов нет!!!

[Хакер]

alibek не прав, Space прав. WM_QUIT это сообщение, предназначенное потоку, а не окну. До окон оно никогда не дойдёт, это сообщение, в отличие от всех остальных, не будет возвращено функцией GetMessage, не пройдёт трансляцию и диспетчеризацию. Вместо этого, оно приведёт к тому, что GetMessage вернёт 0, чем приведёт к прерыванию цикла обработки сообщений (и, в последствии, скорее всего, к завершению потока).

SLIM не прав, не WindowProc вызывает DispatchMessage, а наоборот. Но к WM_QUIT, как я сказал выше, это не относится.

[SLIM]

SLIM не прав, ни WindowProc вызывает DispatchMessage, а неаоборот. Но к WM_QUIT, как я сказал выше, это не относится.

А я то и имел ввиду. Это просто смотря как прочитать

[Space]

да, да Хакер! Получается, если послать WM_QUIT окну, его получит первым поток?! А окна закрываются, т.к. завершается вся прога, как при End в Бейсике? Или происходит при этом корректная выгрузка форм, как на Unload Me? Мабудь, нет.

[SLIM]

Черт, ложанулся.
Приношу извинения. MSDN так и говорит.

[Хакер]

послать WM_QUIT окну, его получит первым поток?!

Я не знаю, что будет, если послать WM_QUIT окну. Никто не шлёт это сообщение окну, все юзают PostQuitMessage, которая просто помещает его в очередь сообщений потока. Наверное, если в очереди у этого сообщения будет корректный id, но левое значение поля hWnd, GetMessage всё равно его распознает как WM_QUIT, но это из оперы дури. Надо делать так, как сказано в MSDN, а там сказано так:

The WM_QUIT message is not associated with a window and therefore will never be received through a window's window procedure. It is retrieved only by the GetMessage or PeekMessage functions.

Do not post the WM_QUIT message using the PostMessage function; use PostQuitMessage.

А окна закрываются, т.к. завершается вся прога, как при End в Бейсике? Или происходит при этом корректная выгрузка форм, как на Unload Me? Мабудь, нет.

Во-первых, в WIndows нет форм. Во-вторых, WM_QUIT это просто Message-Paradigm-aware способ оборвать цикл, причём это кросс-поточный способ, что важно. Что происходит с окнами после цикла, зависит от разработчиков каждой отдельной программы. Скажу, что в 99% случаев ничего никто с окнами не делает.

[Space]

ну если сравнить посыл потокам WM_QUIT и TerminateProcess - какова разница?

[Хакер]

Если сравнить естественную смерть и пулю в лоб, какова разница? В конечном исходе, никакой. В механизмах и сайд-эффектах, большая.

[Antonariy]

Я не знаю, что будет, если послать WM_QUIT окну.

Ничего не будет

[Space]

будет завершение проги (проверено).

[Space]

В механизмах и сайд-эффектах, большая

О чём я тя и спрашиваю. Мне надо понять разницу, чтобы выявить преимущества и недостатки.

[Хакер]

Какие могут быть преимущества и недостатки у двух принципиально разных вещей?

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

WM_QUIT это документированный способ оповестить поток о том, что пора бы ему закончить крутиться в цикле обработки сообщений. Единственное, что это обеспечивает: выход из цикла (обычно while) по причине того, что условия зацикливания не удовлетворилось.

Никакого иного поведения WM_QUIT не даёт. После ML-цикла может быть всё что угодно, например, хоть это и изврат, новый ML-цикл. И всё. В обоих случаях за тебя твои данные никто не подотрёт, а системные в обоих подотрутся.

Ни один из вариантов не является аналогом VB-шного End-а с принципиальной точки зрения..

[Antonariy]

будет завершение проги (проверено).

Окну или потоку Send или Post, определись. Потому что я проверял SendMessage hwnd, wm_quit. Ни-че-го.

[Хакер]

Эмм... как минимум я бы Post юзал.

[ANDLL]

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

Потому что я проверял SendMessage hwnd, wm_quit. Ни-че-го.

А теперь PostMessage и то же самое.

WM_QUIT это документированный способ оповестить поток о том, что пора бы ему закончить крутиться в цикле обработки сообщений

Вообщето мне всегда казалось что это сообщение - документированный способ потоку из обработчкиа сообщений сообщить своему собственному циклу о том что надо завершаться. Иными словами - WM_QUIT вообще нужен только для использования внутри потока, а не для того что бы корректно чтото делать

[Space]

PostMessage hwnd, WM_QUIT, 0, 0 Проверял на блокноте, блокнот завершается.

[Хакер]

Вообщето мне всегда казалось что это сообщение - документированный способ потоку из обработчкиа сообщений сообщить своему собственному циклу о том что надо завершаться. Иными словами - WM_QUIT вообще нужен только для использования внутри потока, а не для того что бы корректно чтото делать

А я разве что-то другое сказал? Я так и сказал, что это Message-Paradigm-aware способ сказать своему циклу стоп. Не-Message-Paradigm-aware было бы, к примеру, юзание флага.

[Antonariy]

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

Потому что я проверял SendMessage hwnd, wm_quit. Ни-че-го.

А теперь PostMessage и то же самое.

В этом случае сообщение ставится в очередь потока и до окна даже не доходит. А SendMessage непосредственно вызывает оконную процедуру, которая на WM_QUIT не реагирует.

[ANDLL]

А SendMessage оправляет сообщение непосредственно оконной процедуре, которая на него не реагирует.

Кто тебе такой идиотизм сказал? И ты ведь понимаешь что это идиотизм, потому что такого просто быть не может? Учитывая, что ты посылаешь сообщение в другой поток(что следует из условия топика, если ты не прочитал)?

[Antonariy]

The SendMessage function sends the specified message to a window or windows. It calls the window procedure for the specified window and does not return until the window procedure has processed the message.

Еще будут идиотские вопросы?

[ANDLL]

Даа.
Sucks to be you, если читая msdn ты заб(и)ываешь на процесс мышления

[ANDLL]

Мне даже не удивительно, тебе ведь и в глову не приходить - КАК эта функция может совершить чудо вызова оконной процедуры между потоками.
И разумеется если бы тебе пришло в голову об этом задуматься, ты бы прочитал чуть дальше первого предложения и дошел бы до столь редко читаемой тобой секции remarks

[Antonariy]

Упырьте мел, милейший, и ототрите монитор от брызг
Ну забыл про другой поток, с кем не бывает).

[ANDLL]

С кем бывает, это другой вопрос