API SetParent: Помещение потомка позади родителя.

[Денис]

Фсем превед!
В целях создания муляжа аэровской прозрачности панели задач возникла необходимость помещать сразу за целевым окном (Shell_TrayWnd) свое окно, с отрисованным на нем размытым по Гауссу изображением фона. Однако, возникла трудность — следует поместить свое окно в точке 3, как показано на схеме.
Setparent по хендлу Progman'a помещает в точке 1, по хендлу Shell_TrayWnd — в точке 2, оба варианта, как вы понимаете, неприемлимы.
Следующая схема иллюстрирует расположение слоёв окон рабочего стола.

P.S. Прошу администрацию рассмотреть возможность переноса этого топика в раздел для профессионалов, т.к. считаю этот вопрос неординарным.

[Денис]

Делаю так (код в форме1):

Код: Выделить всё

Option Explicit

Private Type RECT
        Left As Long
        Top As Long
        Right As Long
        Bottom As Long
End Type

Private Const WS_EX_TOPMOST = &H8&
Private Const GWL_EXSTYLE = (-20)

Private Declare Function SetParent Lib "user32" (ByVal hWndChild As Long, ByVal hWndNewParent As Long) As Long
Private Declare Function FindWindow Lib "user32" Alias "FindWindowA" (ByVal lpClassName As String, ByVal lpWindowName As String) As Long
Private Declare Function GetWindowRect Lib "user32" (ByVal hwnd As Long, lpRect As RECT) As Long
Private Declare Function GetDesktopWindow Lib "user32" () As Long
Private Declare Function GetWindowLong Lib "user32" Alias "GetWindowLongA" (ByVal hwnd As Long, ByVal nIndex As Long) As Long
Private Declare Function SetWindowLong Lib "user32" Alias "SetWindowLongA" (ByVal hwnd As Long, ByVal nIndex As Long, ByVal dwNewLong As Long) As Long

Dim Handle As Long
Dim HandleDT As Long
Dim wRect As RECT
Dim NewPW As Form

Private Sub Form_Load()

Set NewPW = New Form2
NewPW.Show

Handle = FindWindow("Shell_TrayWnd", vbNullString)
HandleDT = GetDesktopWindow
GetWindowRect Handle, wRect

NewPW.Top = wRect.Top * Screen.TwipsPerPixelY
NewPW.Left = wRect.Left * Screen.TwipsPerPixelX
NewPW.Width = (wRect.Right - wRect.Left) * Screen.TwipsPerPixelX
NewPW.Height = (wRect.Bottom - wRect.Top) * Screen.TwipsPerPixelY

Dim WL As Long

WL = GetWindowLong(NewPW.hwnd, GWL_EXSTYLE)
SetWindowLong NewPW.hwnd, GWL_EXSTYLE, WL Or WS_EX_TOPMOST

SetParent Handle, NewPW.hwnd

End Sub

Private Sub Form_Unload(Cancel As Integer)

SetParent Handle, HandleDT

Unload NewPW

End Sub

Но эффекты получаются поистине фейерические!!!
(сбивается позиция появления меню пуск, игнорируется мой topmost, позиция таскбара смещается к точке 3 на схеме и сам он перестает реагировать на клики мышки)
(чтобы увидеть Form2, сделайте любым способом таскбар полупрозрачным)
Есть идеи, как сделать правильно?

[Хакер]

А какая связь между SetParent и Z-ордером?

[Денис]

А какая связь между SetParent и Z-ордером?

Z-order это же порядок размещения окон слоями по оси Z, я правильно понимаю? Если я понимаю неправильно, то поправьте.

Вообще, говоря "Z-order", я понимаю порядок по оси Z, а не свойство vb'шного класса, имеющего это свойство (извиняюсь за тавталогию).
Так же, говоря "окно", например, я не подразумеваю под этим только объект, порождаемый одним лишь vb'шным классом Form.

[Хакер]

Z-order это же порядок размещения окон слоями по оси Z, я правильно понимаю? Если я понимаю неправильно, то поправьте.

Вообще, говоря "Z-order", я понимаю порядок по оси Z, а не свойство vb'шного класса, имеющего это свойство (извиняюсь за тавталогию).
Так же, говоря "окно", например, я не подразумеваю под этим только объект, порождаемый одним лишь vb'шным классом Form.

Да. Повторяю вопрос.

[Денис]

Да. Повторяю вопрос.

А какая связь между SetParent и Z-ордером?

SetParent устанавливает эту связь между окном parent и окном child. Устанавливает таким образом, что Z child'a всегда болше чем Z parent'a. Нэ?

Если я устанавливаю тулбар child'ом своего окна, то нарушается правильная работа всего десктопа. Мне интересно одно из двух: либо сделать свое окно child'ом тулбара, но при этом поменять их Z-порядок, либо найти окно проводника, находящееся между тулбаром и десктопом, и сделать его parent'ом своего окна.
Либо третий, неведомый мне, вариант Ъ-гуру.

[Antonariy]

SetParent устанавливает эту связь между окном parent и окном child.

Ничего похожего. SetParent делает одно окно контейнером другого. А z-index определяет видимость нескольких потомков в рамках одного контейнера, поэтому для пары родитель-потомок вообще не имеет смысла. Потомок не может быть ЗА родителем.

Мне интересно одно из двух

Вот почему чуть менее, чем все избретатели улучшалок интерфейса стараются сломать то, что работает и к чему все привыкли, чтобы заменить своим улучшизмом? Почему нельзя дополнить, не трогая того, что и так работает?

сделать свое окно child'ом тулбара, но при этом поменять их Z-порядок

Невозможно. И слава богу.

найти окно проводника, находящееся между тулбаром и десктопом

Не понятно. С какой стати там должно быть окно проводника?

Кстати картинка в первом посте тоже лишена смысла. Не считая того, в ней нет различия между z и контейнерами, десктоп является окном самого верхнего уровня и за ним никакого progman быть не может.

[Денис]

SetParent делает одно окно контейнером другого. А z-index определяет видимость нескольких потомков в рамках одного контейнера

Я это и имел ввиду, только сформулировать не мог. Я рассматривал случай: одно окно — один контейнер.

Вот почему чуть менее, чем все избретатели улучшалок интерфейса стараются сломать то, что работает и к чему все привыкли, чтобы заменить своим улучшизмом? Почему нельзя дополнить, не трогая того, что и так работает?

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

С какой стати там должно быть окно проводника?

Не буду разводить демагогию, отвечая вопросом на вопрос, скажу сразу: окно процесса explorer.exe. Это можно проверить в любом альтернативном диспетчере задач, хоть в Spy++

Кстати картинка в первом посте тоже лишена смысла. Не считая того, в ней нет различия между z и контейнерами, десктоп является окном самого верхнего уровня и за ним никакого progman быть не может.

А вот и нет, Progman, это окно, в котором лежит бэкграунд и его потомком является, например, SysListView32, содержащий в себе иконки рабочего стола. Это тоже легко проверить в альтернативном диспетчере задач. (Я использую плагин AceHelper для TotalCmd)

[Antonariy]

Не буду разводить демагогию, отвечая вопросом на вопрос, скажу сразу: окно процесса explorer.exe.

Таскбар сам пренадлежит explorer.exe. А в иерархии окон является потомком десктопа. Так что смысла в этой фразе нет.

А вот и нет, Progman, это окно, в котором лежит бэкграунд и его потомком является, например, SysListView32, содержащий в себе иконки рабочего стола. Это тоже легко проверить в альтернативном диспетчере задач. (Я использую плагин AceHelper для TotalCmd)

Налицо неспособность интерпретировать показания Spy++. А так же тот факт, что ты не разу не сравнил значение, возвращаемое GetDesktopWindow с хендлом того, что вытыкаешь мышкой кагбэ с рабочего стола. В интерфейсе Spy++ Desktop всегда находится в корне иерархии окон и имеет только FIRST_CHILD, что само по себе символизирует.

Простейший тест: заверши все процессы exprorer.exe и попробуй найти десктоп и progman. После него станет несложно сделать единственно верный логический вывод, что на самом деле progman это проводник, у которого оставили лишь список файлов (листвью), растянули его на весь экран и сделали прозрачным.

[Денис]

А тебе лишь бы поспорить? Проводник, это не окна проводника. Проводник это процесс explorer.exe
Я ж говорю, пользуюсь AceHelper'ом. Вот окна о которых я говорил:


Окно десктопа не нашел, буду рад, если ткнут носом.

[Antonariy]

Мне лишь бы научить кого-нибудь уму-разуму, потому что такие опусы только поначалу вызывают смех, а потом только слезы.
"Окна проводника" в данном случае это окна (хендлы), принадлежащие процессу explorer.exe.

Окно десктопа не нашел, буду рад, если ткнут носом.

Оно в этой еретической проге не указано.

[Денис]

Оно в этой еретической проге не указано.

Подозреваю, что это виртуальное окно, как, например, виртуальная папка рабочего стола. Как там де факто подставляется реальная папка в каталоге с профилем, так и тут подставляется хендл окна, какой-нибудь системной службы. Например, ну... например... эээ... нет, у winlogon'a вообще окон нет. Надо поискать по хендлу.

[Хакер]

Виртуальных окон не существует в концепции окон Windows. Есть другие интересные вещи, как, например MessageOnly-окна, у которых нет Z-порядка, ассоциированного DC, которые не перечисляются Enum-функциями (но с успехом ищутся Find-функциями) и т.д, но виртуальных окон нет.

[Joo]

В общем можно сделать так: (правда тут .NET код, я его писал для свлих часиков)

Поместить окно на задний план:

Код: Выделить всё

SetWindowPos(Me.Handle, HWND_BOTTOM, 0, 0, 0, 0, SWP_NOMOVE Or SWP_NOSIZE)

Запретить окну перемещаться на верхний план:

Код: Выделить всё

Protected Overrides Sub WndProc(ByRef m As System.Windows.Forms.Message)
        If m.Msg = WM_WINDOWPOSCHANGING Then
                    Dim wp As WINDOWPOS
                    wp = DirectCast(Marshal.PtrToStructure(m.LParam, GetType(WINDOWPOS)), WINDOWPOS)
                    wp.hwndInsertAfter = HWND_BOTTOM
                    Marshal.StructureToPtr(wp, m.LParam, True)
        End If
        MyBase.WndProc(m)
    End Sub


Код: Выделить всё

Public Const WM_WINDOWPOSCHANGING = &H46
Public Const HWND_BOTTOM = 1
Public Const SWP_NOSIZE = &H1
Public Const SWP_NOMOVE = &H2

<StructLayout(LayoutKind.Sequential)> _
Public Structure WINDOWPOS
            Public hwnd As IntPtr
            Public hwndInsertAfter As IntPtr
            Public x As Integer
            Public y As Integer
            Public cx As Integer
            Public cy As Integer
            Public flags As Integer
End Structure


[Денис]

WndProc

Запахло сабклассингом...

[Joo]

WndProc

Запахло сабклассингом...

Да... я уже забыл что VB6 чуть немного сложнее с этим, но все равно довольно просто.
Таким образом если я правильно понял можно сделать окно не только под всеми окнами но и под конкроетным окном. Если не прав поправьте.

[Денис]

Теперь я понял, почему Aero™ жрёт так много ресурсов!

Представьте себе, в процедуре перерисовки каждого окна, которая может происходить по нескольку десятков раз в секунду (по ситуации), надо скриншотить всё что под окном, применять к полученному скрину гаусса, отрисовывать на окне, а еще ведь есть эффекты подсветки!

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

[Antonariy]

это все отрисовывается на целевом окне, а не на подложке

Ага, в окне чужого процесса (десктоп пренадлежит вообще crss) ты толком ничего отрисовать не сможешь — процесс перерисует его в соответствии с собственными представлениями о том, что там должно находиться.