Такой функции в Win32 API нет. Во всяком случае — документированной.
Но разве мыслимо, чтобы не пытались заткнуть этакую дыру ?
И посему — не сообщит ли кто что-то радостное на этот счет ?
Кстати, вот единственное, на что выводит Google:
/*----------------------------------------------------------------------
Copyright (c) 1998-1999 Gipsysoft. All Rights Reserved.
File: PtInWindow.cpp
Owner: russf@gipsysoft.com
Purpose: function to determine if a point is within a window area
----------------------------------------------------------------------*/
#include "stdafx.h"
extern bool PtInWindow( HWND hwnd, const POINT &pt );
bool PtInWindow( HWND hwnd, const POINT &pt )
{
RECT rc;
if( ::IsWindow( hwnd ) && GetWindowRect( hwnd, &rc ) && PtInRect( &rc, pt ) )
{
return true;
}
return false;
}
Что есть пример крайне наивного "решения", истинное имя которому — PtInWindowRect.
Здравствуйте, kero, Вы писали:
K>Такой функции в Win32 API нет. Во всяком случае — документированной. K>Но разве мыслимо, чтобы не пытались заткнуть этакую дыру ? K>И посему — не сообщит ли кто что-то радостное на этот счет ?
Здравствуйте, Аноним, Вы писали:
А>WindowFromPoint или ChildWindowFromPoint
Да нет, братцы, я о прямо противоположном...
WindowFromPoint, ChildWindowFromPoint, ChildWindowFromPointEx, RealChildWindowFromPoint, —
все они предлагают вам то или иное окно, содержащее заданную вами точку.
Моя задача — обратная: для заданного (но только хендлом, а не алгоритмом) окна определить, содержит ли оно заданную точку.
Здравствуйте, kero, Вы писали:
K>WindowFromPoint, ChildWindowFromPoint, ChildWindowFromPointEx, RealChildWindowFromPoint, — K>все они предлагают вам то или иное окно, содержащее заданную вами точку. K>Моя задача — обратная: для заданного (но только хендлом, а не алгоритмом) окна определить, содержит ли оно заданную точку.
А что мешает вызвать WindowFromPoint и сравнить хендлы? Насколько я знаю, хендлы одного окна должны быть одинаковыми.
K>>Такой функции в Win32 API нет. Во всяком случае — документированной. K>>Но разве мыслимо, чтобы не пытались заткнуть этакую дыру ? K>>И посему — не сообщит ли кто что-то радостное на этот счет ?
SH>WindowFromPoint
Мимо. Помимо того, что это работает только для TopLevel окон, так еще и гимор с дочерними.
В общем, имхо, правильный вариант — получить регион окна и определить вхождение точки в него. Если региона нет — определять как было показано вхождение в прямоугольник. А вообще, конечно, странно, что нет такой функции.
Здравствуйте, SergH, Вы писали:
SH>Здравствуйте, kero, Вы писали:
K>>WindowFromPoint, ChildWindowFromPoint, ChildWindowFromPointEx, RealChildWindowFromPoint, — K>>все они предлагают вам то или иное окно, содержащее заданную вами точку. K>>Моя задача — обратная: для заданного (но только хендлом, а не алгоритмом) окна определить, содержит ли оно заданную точку.
SH>А что мешает вызвать WindowFromPoint и сравнить хендлы? Насколько я знаю, хендлы одного окна должны быть одинаковыми.
Вызвать и сравнить, конечно, можно, и что хендлы одного окна должны быть одинаковыми — это бесспорно.
Но только вот окон может оказаться в результате не одно, а два
Здравствуйте, kero, Вы писали:
K>Такой функции в Win32 API нет. Во всяком случае — документированной. K>Но разве мыслимо, чтобы не пытались заткнуть этакую дыру ? K>И посему — не сообщит ли кто что-то радостное на этот счет ?
Может, попробовать вот так?
LRESULT lr = SendMessage(hWnd, 0, MAKELPARAM(x,y));
bool inWindow = (lr != HTNOWHERE);
Возможно, координаты нужно будет перевести из экранных в оконные, и еще нужно проверить, как оно работает с прозрачностью.
Здравствуйте, Andrew S, Вы писали:
SH>>WindowFromPoint
AS>Мимо. Помимо того, что это работает только для TopLevel окон,
Почему ? Не только.
AS>так еще и гимор с дочерними. В общем, имхо, правильный вариант — получить регион окна и определить вхождение точки в него. AS>Если региона нет — определять как было показано вхождение в прямоугольник.
Само собой, при сборке PtInWindow по кирпичикам без PtInRegion не обойтись.
Но ведь и этого недостаточно. Слишком уж много мозгов было вложено в винды
Короче — для Win2k+ есть еще альфа-канал. Вспомним, что творит с layered-окном LWA_ или ULW_COLORKEY: своего рода альфа-регион.
Т.е. еще и такие кирпичики необходимо учитывать... Это если собирать по кирпичикам.
AS>А вообще, конечно, странно, что нет такой функции.
Но при этом древняя WindowFromPoint, при всех своих ограничениях, как-то же справляется с оконными регионами и альфа-прозрачностью...
Вот я и думаю: а не припрятано ли поблизости нечто такое, что нам всем пригодилось бы узнать ?
AS>>Мимо. Помимо того, что это работает только для TopLevel окон,
K>Почему ? Не только.
Только. Если окно перекрыто другим окном, выше по Z-ордеру, то вернется hwnd более "близкого" окна. В результате мы сделаем вывод, что точка не входит в наше окно, тогда как это не так.
AS>>так еще и гимор с дочерними. В общем, имхо, правильный вариант — получить регион окна и определить вхождение точки в него. AS>>Если региона нет — определять как было показано вхождение в прямоугольник.
K>Само собой, при сборке PtInWindow по кирпичикам без PtInRegion не обойтись. K>Но ведь и этого недостаточно. Слишком уж много мозгов было вложено в винды K>Короче — для Win2k+ есть еще альфа-канал. Вспомним, что творит с layered-окном LWA_ или ULW_COLORKEY: своего рода альфа-регион. K>Т.е. еще и такие кирпичики необходимо учитывать... Это если собирать по кирпичикам.
На альфаканал в это случае надо забить. В данном случае проверяется вхождение точки в регион возможного обновления окна, вне зависимости от его прозрачности, положения Z и т.д.
AS>>А вообще, конечно, странно, что нет такой функции.
K>Но при этом древняя WindowFromPoint, при всех своих ограничениях, как-то же справляется с оконными регионами и альфа-прозрачностью... K>Вот я и думаю: а не припрятано ли поблизости нечто такое, что нам всем пригодилось бы узнать ?
Потому что эта функция _обязана_ это делать — она абсолютно ортогональна заказываемой вами функции, и никоим образом не связана с затребованным вами функционалом.
> Переопределяем обработчик в атакуемом окне — и что получаем? Ответ - > мешок лука за спину >
Ну если уж на то пошло, то можно перехватить более низкоуровневые механизмы и возвращать левый регион.
Posted via RSDN NNTP Server 2.0
Не бойся выглядеть глупо, от этого ты выглядишь ещё глупей!!!
>> Переопределяем обработчик в атакуемом окне — и что получаем? Ответ - >> мешок лука за спину >> S>Ну если уж на то пошло, то можно перехватить более низкоуровневые механизмы и возвращать левый регион.
Переопределение обработчика — стандартный и документированный способ. Левый регион — уже хакерство. В общем, это беспереспективно — NCHITTEST предназначено совсем не для этого, и ты это прекрасно знаешь, а метод подмены понятий — плохой аргумент в обсуждении, ага? Давай не пользоваться приемами, популярными в священных войнах
[..] AS>Переопределение обработчика — стандартный и документированный способ. Левый регион — уже хакерство. В общем, это беспереспективно — NCHITTEST предназначено совсем не для этого,
А для чего? Если окно говорит — HTNOWHERE, то значит так оно и считает. > и ты это прекрасно знаешь, а метод подмены понятий — плохой аргумент в обсуждении, ага? Давай не пользоваться приемами, популярными в священных войнах
> Переопределение обработчика — стандартный и документированный способ. > Левый регион — уже хакерство. >
Я один в один предвидел твой ответ.
> Давай не пользоваться приемами, популярными в священных войнах >
По-большому счёту я это в шутку сказал и даже смайлик поставил.
Posted via RSDN NNTP Server 2.0
Не бойся выглядеть глупо, от этого ты выглядишь ещё глупей!!!
NCHITTEST, безусловно, в тему, но вот, например, "дырка" в оконном регионе — для него все равно HTCLIENT (проверьте, может вру).
Ну и что-то еще в том же духе, сходу не вспомню.
AS>>>Помимо того, что это работает только для TopLevel окон, K>>Почему ? Не только. AS>Только. Если окно перекрыто другим окном, выше по Z-ордеру,
Похоже — Вам topmost подгадил В MSDN-овской статье о WindowFromPoint нет ни слова о top-level окнах.
И это потому, что WindowFromPoint работает и с top-level, и с дочерними окнами. А именно эти категории окон
и противопоставляются (см, например, описания FindWindow и FindWindowEx).
AS>то вернется hwnd более "близкого" окна. В результате мы сделаем вывод, что точка не входит в наше окно, тогда как это не так.
Ни в коем случае не сделаю такого вывода, потому и ветку эту затеял
AS>>>так еще и гимор с дочерними. В общем, имхо, правильный вариант — получить регион окна и определить вхождение точки в него. AS>>>Если региона нет — определять как было показано вхождение в прямоугольник. K>>Само собой, при сборке PtInWindow по кирпичикам без PtInRegion не обойтись. K>>Но ведь и этого недостаточно. Слишком уж много мозгов было вложено в винды K>>Короче — для Win2k+ есть еще альфа-канал. Вспомним, что творит с layered-окном LWA_ или ULW_COLORKEY: своего рода альфа-регион. K>>Т.е. еще и такие кирпичики необходимо учитывать... Это если собирать по кирпичикам. AS>На альфаканал в это случае надо забить. В данном случае проверяется вхождение точки в регион возможного обновления окна, вне зависимости от его прозрачности, положения Z и т.д.
Не понял, почему надо забивать на альфа-канал. Наоборот, с ним бы и разобраться. Ведь если в случае с регионом есть документированная возможность,
так сказать, синтетического решения (PtInRegion), то в случае с alpha=0 — ничего такого не предоставлено...
AS>>>А вообще, конечно, странно, что нет такой функции. K>>Но при этом древняя WindowFromPoint, при всех своих ограничениях, как-то же справляется с оконными регионами и альфа-прозрачностью... K>>Вот я и думаю: а не припрятано ли поблизости нечто такое, что нам всем пригодилось бы узнать ? AS>Потому что эта функция _обязана_ это делать — она абсолютно ортогональна заказываемой вами функции, и никоим образом не связана с затребованным вами функционалом.
А вот это скорее заклинание или попытка гипноза, чем аргумент, кто это тут поминал приемы, популярные в священных войнах ?
AS>>>>Помимо того, что это работает только для TopLevel окон, K>>>Почему ? Не только. AS>>Только. Если окно перекрыто другим окном, выше по Z-ордеру,
K>Похоже — Вам topmost подгадил В MSDN-овской статье о WindowFromPoint нет ни слова о top-level окнах. K>И это потому, что WindowFromPoint работает и с top-level, и с дочерними окнами. А именно эти категории окон K>и противопоставляются (см, например, описания FindWindow и FindWindowEx)
TopMost и TopLevel — это разное. TopLevel — подразумевает верхнее в Z ордере окно относительно данной координаты в данный момент времени.
AS>>то вернется hwnd более "близкого" окна. В результате мы сделаем вывод, что точка не входит в наше окно, тогда как это не так.
K>Ни в коем случае не сделаю такого вывода, потому и ветку эту затеял
Поэтому и говорю, что WindowFromPoint ортогональна поставленным задачам. То, что она проверят (проверяет ли — не уверен, кстати) прозрачность для данного окна — это вполне логично, поскольку имеется виду физическая экранная точка в контексте устройства экрана. Т.е. фактически "чей это тут такой пиксель со значениями (RGB)". Мое же представление о функции PtInWindow — функция, определяющая вхождение координаты (не физической точки) в регион, ограничиваюший возможную область обновления окна.
AS>>>>А вообще, конечно, странно, что нет такой функции. K>>>Но при этом древняя WindowFromPoint, при всех своих ограничениях, как-то же справляется с оконными регионами и альфа-прозрачностью... K>>>Вот я и думаю: а не припрятано ли поблизости нечто такое, что нам всем пригодилось бы узнать ? AS>>Потому что эта функция _обязана_ это делать — она абсолютно ортогональна заказываемой вами функции, и никоим образом не связана с затребованным вами функционалом.
K>А вот это скорее заклинание или попытка гипноза, чем аргумент, кто это тут поминал приемы, популярные в священных войнах ?
Это выражение _моего_ мнения, и тут нет подмены понятий, в отличие от. Так шта мимо, укол не засчитан. Прделагаю больше конструктива. Например, поясните, почему по вашему мнению, должна в данной функции учитываться альфа? Мое мнение — альфа это то, как мы _видим_ это окно на физическом устройстве, к логической точке в нем оно никакого отношения не имеет.
Здравствуйте, Andrew S, Вы писали:
AS>Мое же представление о функции PtInWindow — функция, определяющая вхождение координаты (не физической точки) в регион, ограничиваюший возможную область обновления окна.
Такое определение мне кажется наиболее разумным.
Но сразу возникает другой вопрос: а какой в ней смысл? Вычислить, стоит ли рисовать точку, нарисовать, если надо, а потом при рисовании система будет повторно делать проверки? ИМХО имеем лишнюю операцию.
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
AS>>Мое же представление о функции PtInWindow — функция, определяющая вхождение координаты (не физической точки) в регион, ограничиваюший возможную область обновления окна.
GN>Такое определение мне кажется наиболее разумным.
GN>Но сразу возникает другой вопрос: а какой в ней смысл? Вычислить, стоит ли рисовать точку, нарисовать, если надо, а потом при рисовании система будет повторно делать проверки? ИМХО имеем лишнюю операцию.
Ну, разумность мне тоже сомнительна, впрочем, при хитром отсечении, наверное, есть шанс сэкономить, проверяя на граничных точках. Правда, полезность функции именно в таком виде тоже вызывает вопросы.
Здравствуйте, Andrew S, Вы писали:
AS>TopLevel — подразумевает верхнее в Z ордере окно относительно данной координаты в данный момент времени.
Признавайтесь — это ведь Ваше собственное определение ? В MSDN термин top-level (он же TopLevel) наполняют совершенно иным содержанием.
Но если я тут заблуждаюсь — буду искренне благодарен за ссылку на первоисточник.
AS>Прделагаю больше конструктива. Например, поясните, почему по вашему мнению, должна в данной функции учитываться альфа? AS>Мое мнение — альфа это то, как мы _видим_ это окно на физическом устройстве, к логической точке в нем оно никакого отношения не имеет.
При помощи альфы можно получить разновидность оконного региона. Т.е. включая LWA_/ULW_COLORKEY или 0-значение альфа-канала.
До того мы действительно разве что _смотрим_ сквозь "стекло", теперь же — выбираемся через "дыру" наружу (верхом на мышке).
AS>>TopLevel — подразумевает верхнее в Z ордере окно относительно данной координаты в данный момент времени.
K>Признавайтесь — это ведь Ваше собственное определение ? В MSDN термин top-level (он же TopLevel) наполняют совершенно иным содержанием. K>Но если я тут заблуждаюсь — буду искренне благодарен за ссылку на первоисточник.
Я пояснил, что имелось в виду под Top-Level, может, не стОит придираться к словам? Терминология MSDN в данном случае явно очень неудачна, как и вообще ко многим оконным элементам, сказывается наследие win16. Или вы не согласны, что WindowFromPoint нельзя использовать в данных целях?
AS>>Прделагаю больше конструктива. Например, поясните, почему по вашему мнению, должна в данной функции учитываться альфа? AS>>Мое мнение — альфа это то, как мы _видим_ это окно на физическом устройстве, к логической точке в нем оно никакого отношения не имеет.
K>При помощи альфы можно получить разновидность оконного региона. Т.е. включая LWA_/ULW_COLORKEY или 0-значение альфа-канала. K>До того мы действительно разве что _смотрим_ сквозь "стекло", теперь же — выбираемся через "дыру" наружу (верхом на мышке).
Не согласен. Если регион имеет действительно отношение к отсечению, то тут — в любом случае используется копирование. Либо через системный буфер, либо через буфер приложения. В любом случае, само приложение считает видимым именно всю область, и обновлять (при Update) сможет именно ее всю, включая точки с "прозрачным" цветом. То, что окресности с нулевой альфой или же колоркеем "прозрачны" для input сообщений — ничего не значит _вообще_. Тот же эффект дает стиль WS_EX_TRANSPARENT, и никакого отношения к принадлежности координаты к обновляемому региону окна это не имеет. Опять же, альфа не применяется к элементам управления. В общем, мне мой взгляд (а кто бы сомневался) кажется куда более логичным чем то, что пытаетесь представить вы. У вас выходит NCHITTEST в дефалтной реализации, который к PtInWindow имеет малое отношение
Здравствуйте, Andrew S, Вы писали (а было это всего-то год назад ) :
AS>>Прделагаю больше конструктива. Например, поясните, почему по вашему мнению, должна в данной функции учитываться альфа? AS>>Мое мнение — альфа это то, как мы _видим_ это окно на физическом устройстве, к логической точке в нем оно никакого отношения не имеет.
Представляю случай с альфой в связке с SetLayeredWindoqAttributes (кстати, UpdateLayeredWindow тут не подходит в принципе).
Usage вкратце:
Правый клик по диалогу работает как триггер переключения layered/не-layered для контролов.
Левый двойной клик по диалогу — назначает или отменяет WS_CAPTION диалогу.
Диалог можно таскать прижатой правой кнопкой мышки, а при нажатой клавише CTRL — то же и для контролов.
При этом перемещаются и пары рамок у зрительно распадающегося надвое контролов...
Итак: где "настоящие" точки этих "раздвоенных" контролов ?
Похоже на IntersectRect рамок, но разные оконные искатели очерчивают разное (Spy++, Process Explorer, etc)...
K>разные оконные искатели очерчивают разное (Spy++, Process Explorer, etc)...
Впрочем, в Spy++ (v.6/v.7) просто-напросто глючат оба оконных искателя ("Find Window" и "Window Search"),
что и показывает приведенная выше утилитка...
Раз уж сказал, что искатели Spy++ глючат, — придется уточнить:
они не понимают top-level окон с битом WS_CHILD (например — ComboLBox) и "SetParent-ed" таких окон (пример выше).
P.S. А вопрос пред-предыдущего сообщения этой ветки, видимо, только мне и интересен ...
