How can I do that?
The following seems to work:
CreateWindowEx(WS_EX_TOOLWINDOW, szToolWndClass, "Title",
WS_OVERLAPPEDWINDOW | WS_VISIBLE, CW_USEDEFAULT, CW_USEDEFAULT, 240, 320,
hWnd, NULL, hInstance, NULL)
But this doesn’t (the window is not displayed):
CreateWindowEx(WS_EX_TOOLWINDOW, szToolWndClass, "Title",
WS_OVERLAPPEDWINDOW | WS_VISIBLE, CW_USEDEFAULT, CW_USEDEFAULT, 240, 320,
hWnd, (HMENU) IDD_TOOL, hInstance, NULL)
However, it works when I add the WS_CHILD style, but that doesn’t create a floating window.
Top-level windows use the ID slot as the HMENU (or rather, child windows use the HMENU slot as the control ID); so child windows can’t have HMENUs, and top-level HWNDs can’t have IDs.
What’s likely happening is that when you omit WS_CHILD, windows treats the ID as a HMENU, and since it’s not a valid HMENU, fails the CreateWindow call.
Generally speaking, an ID only makes sense in the context of a known container. So in the context of a dialog, IDs make sense, because the dialog owns the controls in it, and the author can ensure there’s no duplicates – and GetDlgItem will do something sensible.
But on the desktop, every window is from a different source, so there would be no way to ensure unique IDs, so the concept wouldn’t really make sense there anyhow.
Your best bet is perhaps to save away the HWND itself, and use it directly when needed.
One thing to be aware of is that when you don’t use WS_CHILD, your new window is actually a child of the desktop window, but is owned by the HWND you pass in, it’s not a child of that window. Enumerating the child windows of that owner window will not return your new window.
Raymond Chen (who’s blog should be considered required reading for all Win32 devs) has a good explanation of the parent vs owner issue here.