Arranging Cascade the CDialogs in MFC with CascadeWindows function - c++

How can I arrange dialogs programmatically in MFC in cascade format, other than simply using SetWindowPos based upon the position of the previously displayed window?
The Dialog position is to be loaded from the registry in my app, so we use:
SetWindowPos(NULL,x,y,cx,cy,SWP_NOZORDER);
...for the dialog. After that if we use the CascadeWindows function it doesn't seem to work for this Dialog, though it works for other dialogs in the same parent window. It seems the CascadeWindows function has no effect on windows that have called SetWindowPos; can anybody please confirm?
If so, do we have to use only SetWindowPos to arrange the dialog's cascade, or is there another way?

Check if your dialog is having window style: WS_EX_TOOLWINDOW or WS_EX_TOPMOST. CascadeWindows will not arrange windows with that styles.
I tried an MFC sample dialog based application with the following code:
void CTestCascadeDlg::OnBnClickedOk()
{
this->SetWindowPos( NULL, 100,100,500,500, SWP_NOZORDER );
CascadeWindows( NULL, MDITILE_ZORDER, NULL, NULL, NULL );
}
And I could observe that my dialog was cascaded successfully.

Related

Make focused modeless dialog topmost

So I have my main dialog that calls modeless dialogs through this function (this is the legacy code on the project):
void MyClass::ShowDialog(CDialog* dialog)
{
if (!IsWindow(dialog->m_hWnd))
{
return;
}
int nCmdshow1 = dialog->IsWindowVisible() ? SW_HIDE : SW_SHOW;
dialog->ShowWindow( nCmdshow1 );
}
Problem: all sub dialogs stay on top of my main dialog.
Desired behavior: whichever's focused (they are all modeless), be it the main dialog, or sub dialogs, I want it to be the topmost dialog. Thank you!
Note: I already tried on my main dialog's OnInitDialog() these but didn't work:
1. SetWindowPos(&this->wndTop,0,0,0,0,SWP_NOMOVE|SWP_NOSIZE);
2.SetWindowPos(&this->wndTopMost,0,0,0,0,SWP_NOMOVE|SWP_NOSIZE);
EDIT
Also, sub dialogs are created this way:
m_subDlg1->Create( SubDlg1::IDD, this );
As long as there is an owner relation between two windows. the owner of a window can never be on top of the owned window.
Windows in an owner, parent, child relation always behave the same. The owned/child window is always on top of the parent/owner.
If you want to break this, you have to break the owner/child relation. Let all dialog windows have no owner... than they may float freely.
But: I will expect the you program doesn't behave better. Even worse. User might search windows that are deep below covered under other windows. And they will never get in front, when your program gets active.
See the description about parent/child/owned windows here. Also this article might be helpful.
Edit: The problem is that internally the MFC sets the main window as an owner if no parent is given. Only the call to BOOL Wnd::CreateDlgIndirect(LPCDLGTEMPLATE lpDialogTemplate, CWnd* pParentWnd, HINSTANCE hInst) allows to leave pParentWnd NULL.
So you may create the window as normal, but use SetParent(NULL) after it was created. Again the MFC ASSERTs this. SO you may use the API function and the handle of your dialog.

MFC child (WS_CHILD) dialog has different style than parent

I have 2 dialog and I´m trying to embedded one to another. It is accomplished by setting style of embedded dialog to WS_CHILD. It works correctly, but embedded dialog has wrong (default windows) style. Is it windows thing, that cannot be changed, or is there any way to fix it? I tried to changed all options for both dialogs in resource editor, but none seems to work.
Main dialog is normal modal dialog.
Embedded dialog is created in OnInitDialog() of main dialog like
CDialog m_dlg1;
m_dlg1.Create(CDialog1::IDD, this);
m_dlg1.SetWindowPos(NULL, 0, 0, 0, 0, SWP_SHOWWINDOW|SWP_NOSIZE|SWP_NOMOVE)
and has Style set to Child in Resource editor.
Result looks like
How I want it to look (it looks like it with popup and overlapped style)
Thanks in advance for any help, or recommendations.

how to make a clickable button in c++ win32

anyone can tell me how to use a bitmap as a button, actually i can create a static control and could set a picture to it but the thing is that i don't know how to use it as a button, i am using c++ win32.
This is how i create the bitmap
Code:
HWND Profile_Stuff(HWND hWnd, HINSTANCE hInst)
{
HWND Profile_Pic;
Profile_Pic = CreateWindow("STATIC", NULL, SS_BITMAP|WS_CHILD|WS_VISIBLE|WS_TABSTOP|WS_BORDER, 5,5,33,33, hWnd, NULL, hInst, NULL);
HBITMAP hBmp = (HBITMAP)LoadImage(NULL, "camera1.jpg", IMAGE_BITMAP,0,0,LR_LOADFROMFILE);
if(hBmp == NULL){
MessageBox(NULL, "Error while loading image", "Error", MB_OK|MB_ICONERROR);
}
SendMessage(Profile_Pic, STM_SETIMAGE, (WPARAM)IMAGE_BITMAP, (LPARAM)hBmp);
return 0;
}
then i call the function in main window wm_create message handler which creates it successfully, now i don't know to use it as a button, like we have a picture of an advertisement at the bottom of bit torrent application.
i am using visual studio c++ with win32 api.
If you want a button control, you should create a button control. The visual representation can be controlled by the application. To do so, specify the BS_OWNERDRAW Button Style. A button control with this style sends a WM_DRAWITEM message to the control parent whenever a visual aspect has changed. The control parent can then render the control as it sees fit.
An introduction to owner-drawn controls is available at Custom Controls. If you wish to retain some parts of the button control (e.g. its border), see Using Visual Styles with Custom and Owner-Drawn Controls for details (or DrawFrameControl if you aren't using Visual Styles).
Fully working sample code for an owner-drawn button control can be found in this answer.
In Windows, the windows belong to a class, a the class defines the windows procedure for all windows of that class, meaning how they react to events.
If you create a STATIC window, it will not react to any click and will not be useable as a button.
You could create a custom class, register it along with a custom windows procedure able to mimic a BUTTON. But unless you have very special requirements just create an owner drawn button as shown in #IInspectable's answer

Parent-Less Button

Can I create a button without a parent in WINAPI?
I tried doing:
CreateWindowEx(0, "Button", "BTN", WS_POPUP | BS_PUSHBUTTON, 0, 0, 15, 15, nullptr, nullptr, nullptr, nullptr);
then setting the parent to a specified window later on and also showing the button using ShowWindow. This indeed created a fine looking button.
However, the button has no ID and cannot be Identified in WM_COMMAND because the ID is 0.. If two buttons were parentless, there'd be no way to tell them apart. Now if I give it an ID through the HMENU parameter:
CreateWindowEx(0, "Button", "BTN", WS_POPUP | BS_PUSHBUTTON, 0, 0, 15, 15, nullptr, 15, nullptr, nullptr);
GetLastError() prints "Invalid Menu Handle" and the button will not be created.
If I give it no parent and WS_CHILD, it will say cannot create a top level child window which is understandable.
So what I did was I set the Parent to GetDesktopWindow() and give the button an ID. That works but the button isn't parentless..
So is there a way to give a button an ID (So as to identify it in WM_COMMAND) and at the same time, have its parent NULL so that I can set the parent later? How does Windows Forms do it? The buttons can be parentless until you do Form.add(ButtonName);
Can the same effect be achieved in WINAPI?
This is appears on its face to be a very silly sort of question.
Button controls are by definition child controls, so the call to the CreateWindowEx function you use to create the button should also be specifying the WS_CHILD style.
Of course, as you mention, you cannot create a child control with no parent; you'll get an error. There is no such thing as a top-level child window.
So then, the answer to the initial question
Can I create a button without a parent in WINAPI?
is clearly no. Buttons are child controls, and all child controls must have a parent.
Just because Windows let you get away with specifying the WS_POPUP flag when you create a button control doesn't mean that it's a valid combination.
I strongly recommend re-reading the documentation for the CreateWindowEx function. In particular, note that the hMenu parameter is overloaded with respect to its meaning. If you are creating an overlapped or pop-up window (WS_OVERLAPPED or WS_POPUP), it specifies a handle to a menu. If you're creating a child window (WS_CHILD), it specifies the identifier of the child window. The fact that the same parameter is used for both things, depending on the style of the window, should tell you something.
How does Windows Forms do it? The buttons can be parentless until you do Form.add(ButtonName);
They most certainly cannot. The button controls are not created until you add them to a form or other parent control. The System.Windows.Forms.Button class constructor does not create a Win32 window. It just holds a collection of necessary styles used to create the underlying Win32 window when appropriate.
You could, of course, do the same thing by writing a C++ Button class. A simple implementation would just have member variables corresponding to the parameters of CreateWindowEx and a Create member function that would actually call CreateWindowEx to create the Win32 window once all of the members had been set. The Create method could throw an exception if one of the necessary members had not yet been set to a valid value.
I solved it. I had to pass HWND_MESSAGE as the Parent Parameter. When you call SetParent, that parameter gets changed to the Parent's handle and all is well.
No, this really is not a "solution" to the problem. As kero points out, you've simply set the button control's parent to the message-only window. Again, this might appear to work, but it's a rather strange thing to do and I hardly recommend it as a solution.
If you really want to hack it, I recommend creating your own hidden top-level window to use as a parent for your "unparented" child controls. Then you could use the same trick of calling SetParent to reparent them.
I solved it. I had to pass HWND_MESSAGE as the Parent Parameter. When
you call SetParent, that parameter gets changed to the Parent's handle
and all is well.
No, you didn't get "Parent-Less Button": the parent window of your message-only button is the "main" message-only window (class "Message").

Opening a window in other method than `DialogBox`

I have a dialog IDD_WINDOW_INFO that has to be opened when the user clicks a button or a menu item in my C++ Win32 application. The method that I use to open the dialog is in the following line:
DialogBox(hInstance, MAKEINTRESOURCE(IDD_WINDOW_INFO), hMainWindow, WindowInfoProc);
but my problem is that when that dialog box opens, the user cannot operate with the main window of my application. So what can I do to have both windows active?
You are calling DialogBox which shows the dialog modally. When a modal dialog is shown, the other owning windows are disabled and only the modal dialog can accept input. That is the very essence and intent of a modal dialog. The idea is that you can interact only with the dialog, and cannot interact with the other windows.
Another answer suggests passing NULL as the hWndParent parameter to DialogBox. That's not the solution. That will result in you having an unowned window. Yes, you will be able to interact with the main window, but when you do so your main window will appear on top of the dialog. That's because the ownership is set incorrectly. I recommend that you read about window ownership to better understand the issue.
The correct solution to your problem is to show a modeless dialog. A modeless dialog allows you to interact with the other windows in your application. And that's exactly what you ask for in the question.
You show modeless dialogs by calling CreateDialog followed by ShowWindow. This MSDN article shows an example: Using Dialog Boxes.
If I recall correctly, you can either pass NULL instead of the handle to the parent window or change the dialogbox type in the resource editor.
That is an easy way to do it, however the following is certainly better - since having an unowned dialog isn't your best choice.
The point is that DialogBox() will create a modal dialog window, while CreateDialog does not. Modal dialogs disable the parent window.
From MSDN: A modeless dialog box neither disables the owner window nor sends messages to it.
That should solve your problem.
CreateDialog(hInstance, MAKEINTRESOURCE(IDD_WINDOW_INFO), hMainWindow, WindowInfoProc);
ShowWindow(hWnd, SW_SHOW);