Child Windows that does not occupy client area

Question

In the Win32 API (pure win32), The Menu bar does not occupy any area from the client area of the window. Which means the origin coordinates of the client area is right under the menu bar to the left.

When we create child window controls using CreateWindow (or any other method), that window takes some area of the client-area.

eg:- Creating a button which is at (xPos = 0, yPos = 0) and (width=width_of_client_area, height=20).

After creating the button if you'll use a GDI function like this, it'll be drew below the button:

Rectangle(hdc, 0,0, 200, 200);

But when creating a menu bar, it doesn't occupy client area. (GDI will not be drew under menu).

FINAL QUESTION: How can i create a control on my parent window like the menu bar ?

You could try msdn.microsoft.com/en-us/library/windows/desktop/… — chris
Menus have built-in support from the operating system. (They're part of it.) — Ken White

Captain Obvlious Captain Obvlious · Accepted Answer · 2013-05-19T06:35:02

The menu is rendered in the non-client area of the window, which is driven by a completely different set of window messages. Keep in mind that you don't actually create child windows for these types of controls. You will need to provide all the rendering and event handling for the customization you want to add. This means that if you want to add a button or checkbox you will need to implement it yourself. You can get your started with a handful of steps but there may be other things that need to be done depending on your requirements.

The first step is to process the WM_NCCALCSIZE message. This will allow you to adjust the size of the non-client area so that you have more space to draw the custom control. Basically you will pass this message on to the default window proc then modify the location and dimensions (just drop the top down X pixels) before returning.

The next step is to handle WM_NCPAINT message. Pass the message on to the default window proc then draw your custom visuals in the area you have reserved. You will be working with a window DC so you can draw to the entire window. It's important to keep this in mind so you don't destroy anything in the client area.

The last item that needs to be done is to handle mouse messages like WM_NCMOUSEMOVE. If the mouse event occurs outside the area where your control is located pass the message to the default window proc, otherwise handle the message yourself and skip the default proc. you will need to manage some state data for keeping track of when a button is down or not so as not to cause conflicts with the default window proc.

Keep in mind that when you want to draw directly to the non-client area you need to call GetWindowDC() instead of GetDC() to acquire a device context.

[Note: A good Google dance will be something like "WinAPI non-client area"]

Child Windows that does not occupy client area

1 Answers