Порядок, в котором дескрипторы возвращаются значимым EnumWindows?
Итак, я нашел обходной путь - включить перемотку HttpRequest. Для этого мне нужно было добавить этот фрагмент кода в Startup.cs:
app.Use(async (context, next) => {
context.Request.EnableRewind();
await next();
});
Таким образом, исключение UnexpectedEndOfStream не будет выброшено, поскольку поток можно перематывать.
4 ответа
Это возвращает их в порядке Z. Сначала самое верхнее окно с WS_EX_TOPMOST набор, до самого нижнего окна с WS_EX_TOPMOST set, затем самого верхнего окна без WS_EX_TOPMOST, хотя к самому нижнему окну без WS_EX_TOPMOST. Обратите внимание, что видимость не является определяющим фактором, таким образом, невидимое окно, это выше в Z-порядке, чем видимое окно, все еще появится перед ним.
РЕДАКТИРОВАНИЕ :
очень маловероятно, что Вы могли использовать это, как Вы хотите, просто беря первый возврат от EnumWindows. Мало того, что Ваше новое окно вряд ли будет первым возвратом, но у Вас было бы состояние состязания, где другие окна могли быть открыты тем временем. Вы могли, однако, сохранить список всех известных окон для приложения, и когда необходимо найти недавно открытое окно, назовите EnumWindows и сравните дескрипторы окна с теми, которые в списке. При нахождении того, который имеет корректный класс и подпись (Вы могли бы даже проверить, что именно к правильному процессу с GetWindowThreadProcessID), не в Вашем списке, затем Вы нашли новое окно.
В Ваших целях, тем не менее, Вы можете быть еще лучше обслужены путем установки рычага CBT и наблюдения за уведомлением HCBT_CREATEWND. Посмотрите справку MSDN на [1 116] SetWindowsHookEx() и CBTProc обратный вызов для получения дополнительной информации.
Уровень уверенности о порядке перечисления:
Много комментариев и другие ответы на этот вопрос упомянули отсутствие точной документации в MSDN о порядке, в котором EnumWindows окно возвратов обрабатывает. И действительно, страницы на [1 118] EnumWindows и EnumWindowsProc обратный вызов оба довольно тихи по проблеме. Я предлагаю, как свидетельствуют следующее:
-
А C++ Q& в статье в MSDN magazine действительно говорится конкретно:
EnumWindows перечисляет окна в нисходящем Z-порядке
-
, страница на [1 121]
EnumChildWindowsссылается на порядок в разделе комментариев:дочернее окно А, которое перемещено или изменено местоположение в порядке Z во время процесса перечисления, будет правильно перечислено.
Это подразумевает, что порядок является зависимым Z-порядка. И с тех пор, в описании параметр hWndParent , это говорит это:
, Если этот параметр является ПУСТЫМ, эта функция эквивалентна EnumWindows.
можно предположить, что та же логика и упорядочивание относятся
EnumWindows. - Это - заметное поведение этой функции, которая делает его повреждающимся изменением для изменения его. В целом Microsoft была очень хороша о не внесении повреждающихся изменений в заметное поведение. Это не гарантия, но это - довольно безопасная ставка. Вы, более вероятно, найдете, что в следующей версии функция, которую Вы используете, была deprecated— и заменила еще одним "Исключая" version—, чем найти, что его заметное поведение изменилось.
, Конечно, это является все очень академическим в этой точке, так как EnumWindows, вероятно, не, лучшим решением для problem†OP” по крайней мере EnumThreadWindows, вероятно, был бы лучший fit—, но я думал, что это стоило упомянуть для других людей, которые могли бы столкнуться с этим сообщением.
При управлении обоими процессами, можно отправить от первого SendMessage с "HWND_BROADCAST" как первый параметр.
Затем другая программа, когда получают сообщение, может сделать SendMessage к его дочерним окнам.
Порядок не указан в API ( ссылка MSDN ), таким образом, это, как гарантируют, будет ничем в особенности - если бы была гарантия, это было бы явно указано в API. Что происходит, например, если окно создается на полпути посредством перечисления - это становится включенным в перечисление? Это позволяет менеджер окон, который свобода изменить ее реализацию должна он становиться более эффективным, чтобы сделать так.
Однако существует уникальное значение, которое может использоваться для дифференциации между окнами - сам дескриптор окна. В Вашем EnumWindowProc метод, сохраните дескриптор окна для каждого окна соответствия - Вам нужен он так или иначе для отправки сообщений в окно.
Если бы в документации ничто не говорится о порядке перечисления, я Настоятельно рекомендовал бы, чтобы Вы избегали любых предположений. Несколько сообщений на блоге Raymond Chen (blogs.msdn.com/oldnewthing) показали бы Вас, сколько приложения там, которые полагаются на весь этот недокументированный материал/наблюдение, и что-то идет ужасно неправильно, когда новая версия Windows выходит (если разработчики MS не представляют еще один контейнер для еще одного приложения, которое ведет себя плохо).
Что касается Вашей цели, существует несколько функций, как GetWindowThreadProcessID, GetParent, EnumThreadWindows и EnumWindows, который мог помочь Вам достигнуть задачи.