Created attachment 281740 [details] [review]
When wrapping a foreign W32 window, don't forget to store its HWND

When that window is later used as a parent for a GDK child, the call to
CreateWindow*() will fail, because its HWND is 0.

Review of attachment 281740 [details] [review]:

See comment

::: gdk/win32/gdkwindow-win32.c
@@ +744,2 @@
   window->depth = gdk_visual_get_system ()->depth;
+  GDK_WINDOW_HWND (window) = anid;

let's use impl->handle instead ?

Why?

gdkevents-win32.c:1900
>      else if (msg->message == WM_CREATE)
>	{
>	  window = (UNALIGNED GdkWindow*) (((LPCREATESTRUCTW) msg->lParam)->lpCreateParams);
>	  GDK_WINDOW_HWND (window) = msg->hwnd;
>	}
>      else

although gdkwindow-win32.c:650
>      /* HB: IHMO due to a race condition the handle was increased by
>       * one, which causes much trouble. Because I can't find the 
>       * real bug, try to workaround it ...
>       * To reproduce: compile with MSVC 5, DEBUG=1
>       */
># if 0
>      gdk_win32_handle_table_remove (GDK_WINDOW_HWND (window));
>      GDK_WINDOW_HWND (window) = hwndNew;
>      gdk_win32_handle_table_insert (&GDK_WINDOW_HWND (window), window);
># else
>      /* the old behaviour, but with warning */
>      impl->handle = hwndNew;
># endif

using a macro to assign the new value seems bad practice...

ok, let's push this with the macro for consistency.

Review of attachment 281740 [details] [review]:

Please push.

Attachment 281740 [details] pushed as 31d08bd - When wrapping a foreign W32 window, don't forget to store its HWND

Created attachment 282626 [details] [review]
gdkwindow-win32.c: Fix build on MSVC by casting old_ptr to HWND

Hi,

Unfortunately, I have to reopen this... this broke the build on MSVC as it is more strict on the types when we try to do a value comparison.  Let's cast old_ptr to a HWND...

With blessings, thank you!

Review of attachment 282626 [details] [review]:

Looks good.

Review of attachment 282626 [details] [review]:

Hello Nacho,

Thanks for the review.  The patch was pushed to master as 781846e5.  Shall we push the patches here to gtk-3-12, as this issue hits all releases of GTK+-3.x?

With blessings, thank you!

You've reopened the wrong bug, you actually wanted to comment on bug 726224

Hello LRN,

Yup, sorry...

Thanks though.

Blesings!