2009/3/18 Vincent Povirk madewokherd+8cd9@gmail.com:
On Wed, Mar 18, 2009 at 9:09 AM, Nicolas Le Cam niko.lecam@gmail.com wrote:
On Win2k after the last SHAppBarMessage(ABM_REMOVE, &abd) call, a ABN_POSCHANGED is sent to windows[2].hwnd, but at that time user data has been set to null :
Remove first appbar * second appbar receives ABN_POSCHANGED notification * third appbar receives ABN_POSCHANGED notification Remove second appbar * third appbar receives ABN_POSCHANGED notification Remove third appbar * third appbar receives ABN_POSCHANGED notification
In short, it ignores the ABN_POSCHANGED notification with null user data if it's the last appbar being removed that receives it.
The current patch only change the test's behaviour for this case, as registered_count will only be null before the last SHAppBarMessage(ABM_REMOVE, &abd) call (and before the first SHAppBarMessage(ABM_NEW, &abd) call but at that time you can't get notifications)
If you can really get ABN_POSCHANGED notifications for an appbar after it's removed, you should remove SetWindowLongPtr(windows[1].hwnd, GWLP_USERDATA, 0); The presence of the info structure doubles as an indication of whether to expect notifications.
It will, of course, go away when we destroy the window.
It makes sense that, when you're removing two windows, removing the second-to-last window will trigger an ABN_POSCHANGED notification on the last window.
It seems odd to me that we are able to get this notification without a message loop. Maybe SHAppBarMessage or DestroyWindow is processing them?
In any case, I think you can remove the calls resetting the GWLP_USERDATA pointer. I included them because I thought it was impossible for a window to get a notification after ABM_REMOVE. I think a notification is being processed late here and causing an inappropriate failure.
Thank you for your work in getting at the cause of this.
Vincent Povirk
I don't think calling SHAppBarMessage with ABM_REMOVE destroy the window and the ABN_POSCHANGED notification is catched between this call and the DestroyWindow one. But this particular behaviour only happens on Win2k and perhaps previous windows versions (should be tested) not on XP and later ones, that's why I wanted to keep your approach and mark this particular behaviour as broken (even if I didn't use the right approach as noticed by Paul) to force wine to behave like recent windows versions