20 replies to this topic

[SKAN]

Sample code and few png-transparent-images would help. You can upload images at <!-- w -->www.autohotkey.net<!-- w -->

[SKAN]

You can grab what you need here:

<!-- m -->http://drop.io/hidde...as ... 16aXA%3D<!-- m -->

The link does not work for me. I do not know your application. I need sample code along with pictures to reproduce the said effect.

Edit. Okay! It is working now. I will check it out.

[SKAN]

SKAN, did you ever make any headway seeing if there was a way around these issues?

I did look into it..

If you add 0x4000000 ( WS_CLIPSIBLINGS ) in every picture's 'options', all visual artifacts are avoided.

SC_MOVE message alters the z-order of the controls. When multiple controls share the same WindowPoint ( parent window coordinate ), MouseGetPos retrieves the hwnd of the control highest in the z-order. Part of the problem is, the highest control in z-order need not neccessarily be the foremost visible control. The other part of the problem is to learn how MouseGetPos treats when clicking through the transparent area of the foremost visible control. I think I will have to experiment with [Real]ChildWindowFromPoint() in lieu of MouseGetPos.

One way to control the z-order of controls is to call SetWindowPos(), but I did not get it right when I last tried it. I have the feeling that I am just few steps away from the solution, but since I have been involved in an another project, I have been postponing my experiment.

Anyways.. here is what I have so far:

<!-- m -->http://dl.dropbox.co...ragControls.zip<!-- m -->

[SKAN]

As for SC_MOVE and MouseGetPos, I noticed that if you just load a bunch of fan stacked images, with no drag code whatsoever, but simply a MsgBox that shows you A_GuiControl of what was clicked, it always registers the bottom-most image.

Confusing Z ordering

<!-- m -->http://webcache.goog... ... -1600.html<!-- m -->


Keywords: SetWindowPos, GetWindow, GW_HWNDNEXT, GW_HWNDPREV, hWndInsertAfter, Z order

Like the previous item, this is a clarification issue. The documentation is not wrong - it's just a bit obtuse in places.

Windows stores Z-order information in a counter-intuitive way. At least to me, with my background of graphics applications, items in a Z-ordered list are stored lowest item first, highest item last. Windows does not do this - in a list of sibling windows, the first window is the one at the top of the Z-order.

For example, here is a screen grab from Microsoft Spy++, looking at the dialog of one of my applications:

Note
The easiest way I have found to think about this is that when you look at a tree display of your window hierarchy in Spy++, then that is a correct spatial representation of the Z-order - i.e. in the screen grab to the left, the higher up a window is, the higher it is in the Z-order.
For example, window 000E0B7A is above the window 000D0B62 in the screenshot, which means it is also above window 000D0B62 in the Z-order. This is about the only scenario where this ordering makes sense.

This dialog contains a tab control, and two child dialogs that are used to display the controls on each tab (they're the last 3 items in the list). The dialogs need to be in front of the tab control - and they are. You can see from the picture that the tab control is last in the list, which means it is at the bottom of the Z-order. The two child dialogs are before the tab control in the list, which means they are above the tab control in the Z-order.

That is a bit confusing, but it gets really confusing with window relationships, as in calls to GetWindow(). To get the window above/below the window you are interested in, you use the constants GW_HWNDPREV and GW_HWNDNEXT. Using GW_HWNDPREV gets you the window before the specified window, which is actually above the specified window. Similarly, GW_HWNDNEXT gets you the next window, which is actually below the specified window.

The problem is compounded with the hWndInsertAfter parameter of the SetWindowPos() function. It is documented as follows:

hWndInsertAfter

Handle to the window to precede the positioned window in the Z order.

So when you call SetWindowPos(), your window will actually be positioned below or behind the window specified in hWndInsertAfter. Again, this seems to me to be counter-intuitive. Similarly, when Windows has to draw the windows using the painter's algorithm, it has to traverse the list in reverse order.

You may be thinking "What's the problem? It makes perfect sense!" - in which case, lucky old you. The rest of us have to try to cope with the slightly counter-intuitive terminology.

[SKAN]

Try this, Trente

IfNotExist, *.png
  Loop 5
   UrlDownloadtoFile, http://www.autohotkey.net/~goyyah/pic%A_Index%.png, pic%A_Index%.png
Loop *.png
   Gui, 1:Add, Picture, xp+64 y32 hwndhWnd%A_Index% Border vI%A_Index% gControlMove
                       +0x4000000, %A_LoopFileLongPath%   ; WS_CLIPSIBLINGS := 0x4000000
Gui, 1:Show, w800 h600, Draggable-Controls
Return
ControlMove:
  Ix := SubStr( A_GuiControl,2 ), sHwnd := hWnd%Ix%
  DllCall( "SetWindowPos", UInt,sHwnd, UInt,0, UInt,0, UInt,0, UInt,0, UInt,0, UInt,0x43 )
  Sleep -1     ; ^ SWP_NOMOVE := 0x2 | SWP_NOSIZE := 0x1 | SWP_SHOWWINDOW := 0x40 = 0x43
  SendMessage, 0x112, 0xF012, 0,, ahk_id %sHwnd%             ; WM_SYSCOMMAND and SC_MOVE
Return

[SKAN]

Does the tiling function need to be updated to work with this? Or is it something that needs to be tweaked with this code?

The Tiling function should called after you load your images. Also set WS_CLIPSIBLINGS for the 'Tiled Background'.

Like:

Gui, +Resize

xcoord := 10
Loop 7
{
   Gui, 1:Add, Picture, x%xcoord% y25 hwndhWnd%A_Index% vI%A_Index% gControlMove
                       [color=red]+0x400000[/color]0, %A_Index%.png   ; WS_CLIPSIBLINGS := 0x4000000
   xcoord += 200
}

Gui, 1:Add, Pic, x0 y0 w157 h157 +0x4000000 hwndTiledPic, %A_WorkingDir%\grey.jpg
TileImage( TiledPic,157,157 )
Gui, Show, Maximize
Return

ControlMove:
  Ix := SubStr( A_GuiControl,2 ), sHwnd := hWnd%Ix%
  DllCall( "SetWindowPos", UInt,sHwnd, UInt,0, UInt,0, UInt,0, UInt,0, UInt,0, UInt,0x43 )
  Sleep -1     ; ^ SWP_NOMOVE := 0x2 | SWP_NOSIZE := 0x1 | SWP_SHOWWINDOW := 0x40 = 0x43
  SendMessage, 0x112, 0xF012, 0,, ahk_id %sHwnd%             ; WM_SYSCOMMAND and SC_MOVE
Return

; Copy / Paste TileImage()