shell32/tests: Fix a test on Win2k platform and above.

[Vincent Povirk]

On Wed, Mar 18, 2009 at 9:09 AM, Nicolas Le Cam <niko.lecam at 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