WaitForInputIdle альтернативный подход [дубликат]
Стандарт C ++ 11 говорит об этом следующим образом
9.5 Unions
В объединении не более одного нестатического элемента данных могут быть активны при в любое время, то есть значение не более одного из нестатических элементов данных может быть сохранено в союзе в любое время.
blockquote>Если хранится только одно значение, как вы можете читать еще? Это просто не существует.
Документация gcc перечисляет это в . Определенное поведение реализации
- A член объекта union обращается с использованием члена другого типа (C90 6.3.2.3).
Соответствующие байты представления объекта рассматриваются как объект типа, используемого для доступа. См. «Тип-караун». Это может быть ловушечное представление.
blockquote>, указывающее, что это не требуется стандартом C.
2016-01-05: через комментарии я был связанный с Отчет о дефекте C99 № 283 , который добавляет аналогичный текст в виде сноски к стандартным документам C:
78a) Если элемент используется для доступа к содержимому union - это не то же самое, что последний элемент, используемый для хранения значения в объекте, соответствующая часть представления объекта значения интерпретируется как представление объекта в новом типе, как описано в 6.2.6 (процесс, иногда называемый «type punning»). Это может быть ловушечное представление.
blockquote>Не уверен, что он много разъясняет, учитывая, что сноска не является нормативной для стандарта.
1 ответ
WaitForInputIdle работает, но не так, как вы предполагаете. Это в значительной степени связано с тем, что документация вводит в заблуждение (или, по крайней мере, не так явно, как она должна быть):
Ожидает, что указанный процесс завершит обработку своего исходного ввода и ожидает ввода пользователем с нет ожидающего ввода или до истечения интервала времени ожидания.
Это почти уголовно неточно. В разделе Примечания отмечается, что
WaitForInputIdleждет не более одного раза за процесс, он никогда не упоминает важные детали. В частности:
WaitForInputIdleвозвращает, как только начальный запуск переместился в точку, где любой поток процесса готов к обработке сообщений. Эти сообщения не обязательно должны вводиться пользователем.WaitForInputIdleбыл изобретен, чтобы позволить процессу связываться с дочерним процессом с использованием протокола на основе сообщений. В качестве конкретного сценария использовался DDE , который больше не используется 1).
WaitForInputIdleне может использоваться как надежное решение вашей проблемы: Ожидание ребенка процесса ". Вам действительно нужно дождаться появления пользовательского интерфейса.Система предлагает два решения, которые вы можете использовать:
- Глобальный CBT hook и дождитесь обратного вызова
HCBT_CREATEWND. Вы можете проверить член CREATESTRUCT lpszClass и / или lpszName , чтобы отфильтровать интересующее вас окно.- Используйте WinEvents и ответьте на событие
EVENT_OBJECT_CREATE.Вызывается глобальный крючок CBT, когда окно приближается к быть создан. Структуры ядра, в которых ссылки
HWNDбыли полностью заполнены, но клиентский вызовCreateWindow[Ex]может по-прежнему прекращать создание окна. В отличие от этого, WinEvent выдается после того, как окно полностью построено и готово к взаимодействию.В общем, решение, основанное на крюке CBT, используется, когда приложение должно обновлять некоторые аспекты окна перед тем, как вызывающий абонент
CreateWindowExвпервые увидитHWND. WinEvents, как правило, являются инструментом выбора при реализации решений для обеспечения доступности или автоматизации пользовательского интерфейса.Дополнительные ресурсы:
- WaitForInputIdle действительно нужно называть WaitForProcessStartupComplete
- WaitForInputIdle ждет какой-либо поток, который, возможно, не является тем типом, который вам интересен
1) Да, я знаю , некоторые приложения могут использовать DDE. Но если Раймонд Чен предложил в 2007 году, что мы должны перестать использовать DDE , я просто передам это как авторитетное руководство.