ok i dont understand what the msdn is trying to say. i just need to know when the taskbar has been resized.
ok so lets assume the taskbar has been changed. whats my code gonna look like. to me the msdn is saying it should look like this:
so how am i suppose to receive notification if it says i should call the ABM_WINDOWPOSCHANGED message when i think i should be reveiving it.
ABM_WINDOWPOSCHANGED
Notifies the system when an appbar's position has changed. An appbar should call this message in response to the WM_WINDOWPOSCHANGED message.
Notifies the system when an appbar's position has changed. An appbar should call this message in response to the WM_WINDOWPOSCHANGED message.
ok so lets assume the taskbar has been changed. whats my code gonna look like. to me the msdn is saying it should look like this:
.data?
abd APPBARDATA <>
.code
.elseif uMsg == WM_WINDOWPOSCHANGED
mov abr.cbSize, sizeof APPARDATA
invoke SHAppBarMessage,ABM_WINDOWPOSCHANGED, addr abdso how am i suppose to receive notification if it says i should call the ABM_WINDOWPOSCHANGED message when i think i should be reveiving it.
The WM_WINDOWPOSCHANGED message is sent to a window whose size, position, or place in the Z order has changed as a result of a call to the SetWindowPos function or another window-management function.
WM_WINDOWPOSCHANGED
lpwp = (LPWINDOWPOS) lParam; // points to size and position data
lpwp=Value of lParam. Points to a WINDOWPOS structure that contains information about the window's new size and position.
Default Action- The DefWindowProc function sends the WM_SIZE and WM_MOVE messages to the window.
Remarks-The WM_SIZE and WM_MOVE messages are not sent if an application handles the WM_WINDOWPOSCHANGED message without calling DefWindowProc. It is more efficient to perform any move or size change processing during the WM_WINDOWPOSCHANGED message without calling DefWindowProc.
What can we make of all of this?
Well, if we DON'T try to intercept WM_WINDOWPOSCHANGED,
then our Window Procedure will let it fall through to DefWindowProc. That being the case, we can look for and handle cases of WM_SIZE and WM_MOVE instead, which are common windows messages.
If we DO try to intercept and handle WM_WINDOWPOSCHANGED, then we WILL NOT generate a WM_SIZE and/or WM_MOVE as a result, and have to handle the event ourselves.
Look for examples that use the WM_SIZE/WM_MOVE messages.
They don't need any fancy data structures,either.