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 ?
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"]
First of all this is not MFC.
Here is a cropped version of the GUI I have been working on:
As you can see there is a bitmap image above the tab control (which uses the default window's handle), I will refer to it as "Blue Bitmap" I have no problems with it, it is functioning perfectly.
The problem I am having is setting another bitmap (from a bitmap file on disk) to the background of the child window (more specifically the tab control child window), replacing the grey colour. Here are some things I did to try and set the bitmap as the background for the child window (the tab).
1) I used the same method as was used to assign the blue bitmap to the window by first importing the bitmap using LoadImage like so:
index->hbmBitmapBanner = (HBITMAP)LoadImage(index->hInstance,L"Images\\horizontal.bmp",IMAGE_BITMAP,0,0,LR_LOADFROMFILE);
Then in the WM_PAINT message:
case WM_PAINT:
{
PAINTSTRUCT ps1;
if (BeginPaint(WINDOWHANDLE,&ps1))
{
HDC hdcBanner = CreateCompatibleDC(ps1.hdc);
HBITMAP hbmOldHorizontal = (HBITMAP)SelectObject(hdcBanner,index->hbmBitmapBanner); // banner
BitBlt(ps1.hdc,0,0,516,101,hdcBanner,5,0,SRCCOPY);
SelectObject(hdcBanner,hbmOldHorizontal);
DeleteDC(hdcBanner);
EndPaint(WINDOWHANDLE,&ps1);
}
break;
}
That code was successful in setting blue bitmap to the window, but not in setting the other bitmap into the window, (with the blue bitmap's variables substituted into, size and orientation changed as well of course). It simply did not display the bitmap on the screen, and the window remained unchanged, yet no functions failed. ALSO, when I swapped the file locations around, it loaded the bitmap into where the blue bitmap was, so there is definitely no failure in the loading function.
2) Using the above code, I tried changing the first argument of BeginPaint to the window handle of the tab control box, this proved yet again of no use, and the window remained unchanged. I also tried changing the first argument of BeginPaint to a child window which is displayed on the information tab, this caused the child window (which is a groupbox) to disappear, yet still no bitmap appeared on the window.
3) As a last resort I stupidly attempted to use this function on the child window
SetClassLongPtr(tab->hTabIndex[0],GCLP_HBRBACKGROUND,(DWORD)GetStockObject(BLACK_BRUSH));
And of course, it didn't work
If it is of any use, here is how I created the tabbing in my window:
TCITEM tie = {0};
tab->hTab = CreateWindowEx(0,WC_TABCONTROL,L"",WS_CHILD | WS_VISIBLE,0,101,600,400,
WINDOWHANDLE,NULL,(HINSTANCE)GetWindowLong(WINDOWHANDLE,GWLP_HINSTANCE),NULL
);
Is the main tab control, followed by inserting individual the tabs (i.e the information tab)
TCHAR pszTab1 [] = L"Information"; // tab1's text
tie.pszText = pszTab1; // the tab's text/caption
TabCtrl_InsertItem(tab->hTab, 0, &tie); // insert the tab
Additional info: The tab control, and the windows are working/interacting perfectly apart from this. I was testing/attempting this for only one tab, because I knew if it worked on one tab, then it would work on all the tabs, hence saving time.
I have Programming For Windows Fifth Edition, by Charles Petzold beside me as reference, and there is a rather large section on bitmaps, but he doesn't go into talking about loading a bitmap to a child window, the closest he gets is using a bitmap in a menu, which is completely different than a window.
I think that the issue here is that Windows Common Controls do not interact with your application via your main thread's window procedure but via their own (system-defined) window procedures.
So, for example, when your tab window redraws itself, it does not do so in response to a WM_PAINT message arriving at the window procedure defined in your code. You should be able to verify for yourself that this is so by examining the window handles of messages passed to your window procedure, eg WM_PAINT.
If you wish to 'tap into' the default behaviour of a common control you have to 'subclass' it (see here) but in my experience attempting to change the re-draw behaviour is generally problematic.
In the case of a tab control the best thing to do is create an array of child windows sized to the client area of the tab control and arrange that the one displayed at any one time corresponds to the tab that is selected.
If you're using C++ you might consider creating a base class to wrap these windows in which the background (bitmap) drawing is handled. You can then derive a series of wrappers to handle each individual tab. I've used exactly this approach in the past and it works well.
It may be helpful to bear in mind that the tabs of the tab control do not extend over the whole of the control's client area but are just literally the tabs themselves. I don't remember the details but I think they are handled internally by the control and that manipulating them in any way is rather trick, even when the control is subclassed - may be wrong about that.
Hope that helps.
Cheers, Ian.
i am trying to implement a custom tab control in my win32 window, for that i have used a layered window which is child of the main app window (for the main tab control) and independent windows for individual tab items.
My problem: Whenever i move the main app window, the control window moves along with it (because its the child window) where as the individual tab item windows remain on their position. Can anyone guide me how to to get the tab items windows move along with the main app window concurrently? I can not set the item windows as child of the app, so please base your suggestions on that.
You should redesign your tab to be a child window. Otherwise your attempts to make it work is nothing but a desperate try to fix the thing made bad in first place.
Still if you feel like sticking the original plan, you need to hook/subclass the main app window and handle its movement and sizing messages (WM_MOVING and friends) so that your handler could update your popup/tab window position respectively.
I want to be able to open a GUI application using CreateProcess in a main process and have the GUI display in a window I create from within the main process. Does anyone know how to achive this? Thanks!
If you are in control of both applications then yes.
This is how screen savers display in the screen saver control panel - the control panel passed the dialogs window on the command line, and the .scr file - which is just a simple exe - creates its window as a child using the given hwnd as its parent.
Capturing a previously written top level window and forcing it to exist within your own frame is however not well supported.
Again, it is something you can easilly try: I wrote a test app that created a empty frame window, did a FindWindow for copies of Notepad, and reparented the notepad window to be a child of my frame.
So it does work: in this simple scenario at least, but there is no guarantee: more complex applications that modify their own frame styles might very well break, additionally having a child window and parent window on different threads introduces the possibility of deadlocks.
No you can't do this.
Something that might work... You could start the process though, and then using the window handle apply a series of changes to the window to take off the frame. Then you could move it to the position of some other placement control in your window and when you have move/resize events you also resize this child window.
I want to create a Window like when a context menu pops up or clicking the menubar. I want a Window that will be like this and that I can take over its paint event. Sort of like what is created when you select a sub tool in Photoshop.
EDIT:I want to know how to create controls like the one that comes when you select a sub tool in Photoshop, these do not seem to have a parent window. Those little description popups are a good example of this type of window, and menu items, those rectangles have no parent window.
Thanks
EDIT2: see this: http://cdn-viper.demandvideo.com/media/CB3C805F-421E-45AE-8359-39D59D8F0165/jpeg/20412728-192C-462A-AF8E-1F30BA77AE05_2.jpg
You will notice the window for the sub tools, it is not constrained to a parent window.
But how do they get a nice shadow
around it, and how does it still stay
with the main window without a parent?
That's your real question.
There are several ways of getting the shadow. One is that the window is actually two windows, the "shadow" plus the "main" window.
When you create the flyout window (that's what it's called), you position it near the toolbar. If the toolbar gets a WM_MOVE message, it's your responsibility to call MoveWindow() on the flyout to keep it lined up.
Edited to add
The dwExStyle parameter of CreateWindowEx() should include WS_EX_LAYERED and probably WS_EX_TRANSPARENT, because the 'shadow' will use alpha blending. The hWndParent parameter is the application's main window. The x and y parameters must be calculated as an offset of whatever button the window is to be associated with.