Сразу скажу я очень далек от WinApi. Задача такая получить список окон на рабочем столе которые входят в определенный квадрат, например:

Нужно получить окна которые входят в квадрат 200х200(top,left) 500х500(width,height).

Посмотрев как можно вообще получить список окно я нашел только EnumWindow, но это как то не совсем то что я ожидал. В идеале получить бы массив этих окон, и получить то что выше всех. Подскажите в какую сторону мне посмотреть ?

Вы правильно смотрите в сторону EnumWindows, эта функция перечислит все окна верхнего уровня. Вам останется только:
1. Получить координаты каждого (GetWindowRect)
2. Проверить их на пересечение с вашим квадратом (IntersectRect)
3. В случае, если пересечение существует - добавить дескриптор окна в Ваш список.

Добавлено через 3 минуты и 3 секунды
Выше всех будет либо самое первое, либо самое последнее окно, приходящее в callback от EnumWindows

Я думал есть более простой способ, ну мол сразу массив получить. Но ,сделал по вашему совету, только еще добавил проверку на видимость окна IsWindowVisible ,а то уж много лишних каких то окно было, даже те что в трее )))

есть, платишь деньги и тебе за них готовую программу.

глянь еще в сторону функции WindowFromPoint()

Да я не про это, просто вызов callback функции для получения такого списка, уж простите ,но это через жопу. В чем проблема вернуть массив в ф-ции которая возвращает все хэндлы? Так как мне вариант с callback показался как минимум странным, я поэтому и спросил насчет другого решения. В любом случае спасибо за помощь.

В Windows не всё так просто  ИМХО, если бы и была такая функция, то она бы делала тоже самое что и вы. Оберните поиск в функцию в отдельном юните и будет вам супер функция, удовлетворяющая вашим требованиям 

Я собственно говоря так и сделал  Просто изначальное решение не совсем красиво. Я некоем образом не хотел обидеть WinAPI разрабов, но мне просто не ясна логика этого решения, зачем callback ? Я к тому, почему сразу разработчики WinAPI не смогли сделать по человечески. Я слабо знаком с WinAPI, но то с чем сталкивался это просто ужас.

Это сообщение отредактировал(а) ecspertiza - 30.1.2013, 20:24

Почему винду сразу не сделали по человечески ??? это риторический вопрос с твоей стороны.

пожалуй да 

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

Вообще, это на любителя, ИМХО. Кому как нравится. Например, мне больше нравится вариант с callback. Вот у вас есть конкретное условие, по которому нужно отобрать окна. Но таких условий у разных разработчиков могут быть тысячи. Разработчикам Windows нужно было реализовать все возможные и невозможные варианты? Разве не разумнее сделать один общий шаблонный механизм, который бы подошёл всем? И тут они поступили логично: внутри реализации EnumWindows() они перебирают все окна в цикле и для каждого окна вызывают вашу функцию, внутри которой вы уже любыми изощрёнными способами определяете - нужно вам это окно или нет.
Ну, так как-то... 

Во первых экономили память (во времена Windows 1.0 ее было не много   )
А во вторых из callback'а можно сделать массив, а вот наоборот нельзя. Поэтому и взяли более общий вариант.

Да нифига d WinAPI есть функции при постоянном вызове которой будет возвращать данные, а если данных нет то вернет FLASE говорящей что пора заканчивать перечисление. И это сто раз лучше callback хотя б потому что не надо статической делать в классе.

В multithread будут проблемы. Да и в реализации (со стороны Windows) это сложнее. Так что MS тут сэкономила себе работу.


Это сообщение отредактировал(а) xvr - 31.1.2013, 16:10

И что потом делать с этим массивом? Как освобождать?
Это нужно было придумывать целую церемению по правильному освобождению массивов.
Что было бы чревато последствиями забывания оного, и порождало бы возмущенные вопросы типа: "нахрена мне этот массив, когда я ищу одно окно?".

Колбэк, имхо нормалное решение. Самое универсальное, и самое эффективное.
Каким и должен быть низкоуровневый интерфейс.

Добавлено через 1 минуту и 55 секунд
И вообще, вы судите о винапи с сегодняшней точки зрения.
А она писалась в 80-х годах прошлого века.

даже если судить о ней "с сегодняшней точки зрения", максимум, что может быть эффективнее - это колбек, которому передается не один дескриптор, а сразу "пачка". Актуально будет в многооконной системе ( > 10-100 тыс. top-окон ), от которой нас сейчас отделяет совсем немного  (возможно как раз сдерживающим фактором является API, которое в этих условиях будет подтормаживать не особо шустрые машинки ).

И то, скорее всего первым делом появится вопрос: "а насколько такая `пачка` актуальна, т.е. синхронизирован ли ее порядок и нужно ли проверять каждый ее дескриптор на существование?" Не могу представить себе, чтобы на момент такого обхода блокировалась вся подсистема GUI, а ведь именно это потребуется, чтобы дать Вам гарантии, что массив актуален.

В идеале, там "над API" должны сидеть люди, которые просчитывают нагрузку, которую может сгенерировать неграмотный код, и сопоставляют, насколько такие инструменты будут целесообразно вводить простым смертным. Наверняка есть критический порог нагрузки, который конкретные API никогда не будут генерировать, а это же целая наука. Судя по тому, что API мало меняется, но очень сильно расширяется - такой критический порог уже давно достигнут, и более глубокий апгрейд решается уже на системном уровне, где исключается возможность неграмотных манипуляций с системой.