В свете недавнего обсуждения Meta жалуясь на то, что на такие вопросы, как этот, «не было должным образом дан ответ», я попытаюсь дать ответ на этот вопрос. Не означает, что я думаю, что ответ меклариана плохо — на самом деле, далеко не так. Но его явно посчитали неудовлетворительным, так что, возможно, я смогу добавить некоторые дополнительные сведения.
Ваша проблема возникает из-за довольно распространенной путаницы в отношении того, что на самом деле представляет собой окно рабочего стола. Функция GetDesktopWindow
делает точно то, что должна задокументировано: возвращает дескриптор окна рабочего стола. Однако это не то окно, которое содержит значки рабочего стола. Это совершенно другое окно, впервые появившееся в Windows 95. На самом деле это элемент управления ListView
, настроенный на представление «Крупные значки», с реальным окном рабочего стола в качестве родителя.
Рэймонд Чен, разработчик из группы Windows Shell, предоставляет некоторые дополнительные сведения в следующей статье из конфиденциальной информации Windows: Остатки Windows 3.0
<эм>[ <сильный>. . . ] Если в Windows 3.0 значки на рабочем столе представляли собой свернутые окна, то в Windows 95 рабочий стол действовал как контейнер значков.
Рабочий стол Windows 95 на самом деле был окном, созданным Проводником, которое закрывало ваш экран (но располагалось под всеми другими окнами на вашем рабочем столе). Это было окно, в котором отображались ваши значки. Под ним по-прежнему находилось окно рабочего стола оконного менеджера (окно, которое вы получаете, если вызываете GetDesktopWindow), но вы никогда его не видели, потому что оно было закрыто рабочим столом Windows 95 — точно так же, как деревянная панель в подвале дома моего коллеги. покрыл оригинальную стену и капсулу времени за стеной.
<эм>[ <сильный>. . . ]
Этот дизайн рабочего стола практически не изменился с момента его появления в Windows 95. На типичной машине исходный рабочий стол все еще присутствует, но он полностью закрыт рабочим столом проводника.
Таким образом, окно, возвращаемое функцией GetDesktopWindow
, является настоящим окном рабочего стола, единственным, которое у нас было еще в Windows 3.0. Рабочий стол Проводника (тот, который содержит все ваши значки) — это просто еще одно окно, расположенное поверх окна рабочего стола (хотя и полностью закрывающее исходное), которое не добавлялось до Windows 95.
Если вы хотите получить доступ к окну рабочего стола Проводника, вам нужно выполнить некоторую дополнительную работу помимо простого вызова функции GetDesktopWindow
. В частности, вам нужно просмотреть дочерние окна фактического окна рабочего стола, чтобы найти то, которое Explorer использует для отображения значков. Для этого вызовите функцию FindWindowEx
. чтобы получить каждое окно в иерархии, пока вы не доберетесь до того, который вы хотите. Он имеет имя класса SysListView32
. Вы также, вероятно, захотите использовать функцию GetShellWindow
, которая возвращает дескриптор окна рабочего стола Shell, чтобы помочь вам начать работу.
Код может выглядеть так (предупреждение: этот код не тестировался, и я все равно не рекомендую его использовать!):
HWND hShellWnd = GetShellWindow();
HWND hDefView = FindWindowEx(hShellWnd, NULL, _T("SHELLDLL_DefView"), NULL);
HWND folderView = FindWindowEx(hDefView, NULL, _T("SysListView32"), NULL);
return folderView;
Я отметил там, что на самом деле не рекомендую использовать этот код. Почему нет? Поскольку почти в каждом случае, когда вы хотите получить дескриптор окна рабочего стола (будь то фактическое окно рабочего стола или рабочий стол Проводника), вы делаете что-то не так.
Это не то, как вы должны взаимодействовать с окном рабочего стола. На самом деле, вы вообще не должны взаимодействовать с ним! Помните, как в детстве вы узнали, что нельзя играть с вещами, принадлежащими другим людям, без их разрешения? Что ж, рабочий стол принадлежит Windows (точнее, Shell), и она не давала вам права играть с ее игрушками! И, как любой хороший ребенок, Ракушка может закатить истерику, когда вы попытаетесь поиграть с ее игрушками без спроса.
Тот же Рэймонд Чен опубликовал в своем блоге еще одну статью с подробным описанием очень конкретного случая, озаглавленную Что особенного в окне рабочего стола?
Помимо приведенного им примера, это принципиально не способ автоматизации пользовательского интерфейса. Он просто слишком хрупок, слишком проблематичен и слишком подвержен поломке в будущих версиях Windows. Вместо этого определите, чего вы на самом деле пытаетесь достичь, а затем найдите функцию, которая позволит вам это сделать.
Если такой функции не существует, урок, который нужно усвоить, заключается не в том, что Microsoft просто хочет усложнить жизнь разработчикам. Скорее, вы не должны этого делать в первую очередь.
person
Cody Gray
schedule
17.04.2011