How to show custom messages using a dialog box in Win32 API rather than show them in a default MessageBox function?
I made a function as follows:
void DialogBox_Custom (HWND hWndParent, LPSTR contentToShow)
{
HWND hDialog = CreateDialog(GetModuleHandle(NULL), MAKEINTRESOURCE(IDD_DIALOG1), hWndParent, DialogProc);
if (!IsWindowVisible(hDialog))
{
ShowWindow(hDialog, SW_SHOW);
}
SetDlgItemText(hDialog, IDC_EDIT1, contentToShow);
}
But when I call this function, the dialog box is appearing like millions of times per second and never ending until I close the program by force.
Please kindly someone help me make a custom dialog box where I can show some content sent from the parent window to an EDIT control window in the dialog box.
Use the DialogBoxParam function to create the modal (suspend execution until the window is closed) dialog box.
DialogBoxParam(instance, MAKEINTRESOURCE(IDD_YOURDIALOG), hWndParent, YourWndProc, (LPARAM)contentToShow);
You then have to create a function YourWndProc to handle the messages to paint and offer a mechanism to close the window, to allow execution to continue after your DialogBox() call.
INT_PTR CALLBACK YourWndProc(HWND hDlg, UINT message, WPARAM wParam, LPARAM lParam)
{
switch (message)
{
case WM_INITDIALOG:
SetDlgItemText(hDlg, IDC_EDIT1, (LPSTR)lParam);
return (INT_PTR)TRUE;
case WM_CLOSE:
EndDialog(hDlg, LOWORD(wParam));
break;
}
return DefWindowProc(hDlg, message, wParam, lParam);
}
Modal dialogs are similar to MessageBox: your code gets control back when the dialog is closed. API: DialogBox, DialogBoxIndirect.
Modeless dialogs are similar to windows: you create them with the help of dialog templates and you get the control back immediately, they live powered by message dispatch. This is what you do but you expect them to act as if they were modal. API: CreateDialog, CreateDialogIndirect.
With both modal and modeless dialog you control the dialog with your own DialogProc and you create the dialog with resource dialog template, which automatically creates controls (and you, of course, can add control in code).
Related
I know with Windows notification message, WM_CLOSE refers to closing the window via "X" button on the top right hand corner of the window.
Does anyone know the notification message for closing with File->Exit?
The reason I asked is because I'm trying to implement JNI native code to gracefully close window when user initiated system shutdown. refer to my earlier post (Winapi - SetWindowLongPtr in ShutdownBlockReasonCreate / Destroy implementation of JNI native code) for background.
When clicking on 'X' to close, confirmation dialog box comes up which prevents shutdown reason message from disappearing (when I expect it to disappear after a while). I know File->Exit from menu bar doesn't ask for confirmation, but how do I implement this using windows notification message?
After some digging around the only suggestions I found is to use DestroyWindow. So I tried closing the window using DestroyWindow() function, but it only "Destroys" the window, rather than ending the whole application. Here's my switch statement in my WndProc CallBack function:
switch (message) {
case WM_QUERYENDSESSION:
PostMessage(hWnd, WM_CLOSE, 0, 0);
return 0;
case WM_ENDSESSION:
PostMessage(hWnd, WM_CLOSE, 0, 0);
return 0;
case WM_CLOSE:
DestroyWindow(hWnd);
break;
case WM_NCDESTROY:
RemoveWindowSubclass(hWnd, AppWndProc, uIdSubclass);
break;
}
Any help would be much appreciated!
Cheers
I know with Windows notification message, WM_CLOSE refers to closing the window via "X" button on the top right hand corner of the window.
Actually, when the window's standard "X" button is clicked (or the standard "Close" item on the window's top-left corner menu is selected if enabled, or the window receives an ALT+F4 keystroke), a WM_SYSCOMMAND message is issued to the window with the wParam containing the SC_CLOSE flag. If that message is passed to DefWindowProc() (the default behavior), it then issues a WM_CLOSE message to the window.
See Closing the Window.
It is possible that other conditions can also cause a WM_CLOSE message to be issued.
Does anyone know the notification message for closing with File->Exit?
What happens when that menu item is selected is defined by the application, not the OS. The application can do whatever it wants, including destroying the window immediately if it wants to.
However, that being said, if the menu is a standard Win32 menu, then the window will receive a WM_COMMAND message containing the ID of the menu item that was selected, at least.
The reason I asked is because I'm trying to implement JNI native code to gracefully close window when user initiated system shutdown.
By default, you don't need to do anything for that. The OS automatically closes all open windows during system shutdown. Rather than closing your window manually, you should instead react to your window being closed, if you need to clean up any resources.
When clicking on 'X' to close, confirmation dialog box comes up which prevents shutdown reason message from disappearing (when I expect it to disappear after a while).
Then the application is not handling system shutdown correctly.
Most applications present such a confirmation box in response to receiving the WM_CLOSE message. If the confirmation is aborted, the application discards the message and moves on. However, applications shouldn't prompt the user for confirmation during system shutdown. But not all applications follow that rule.
I know File->Exit from menu bar doesn't ask for confirmation
Again, that is for the application to decide, not the OS.
how do I implement this using windows notification message? After some digging around the only suggestions I found is to use DestroyWindow.
Correct. Or, you can alternatively post a WM_QUIT message to the message queue instead. See the PostQuitMessage() function.
So I tried closing the window using DestroyWindow() function, but it only "Destroys" the window, rather than ending the whole application.
It is the application's responsibility to terminate itself, usually by exiting its message loop when its main window has been destroyed.
Here's my switch statement in my WndProc CallBack function:
There is no need to post WM_CLOSE in response to WM_QUERYENDSESSION or WM_ENDSESSION. Let the OS handle that for you.
If you don't want the confirmation to appear during system shutdown, change your code to something more like this:
bool shuttingDown = false;
LRESULT CALLBACK AppWndProc(
_In_ HWND hWnd,
_In_ UINT message,
_In_ WPARAM wParam,
_In_ LPARAM lParam,
_In_ UINT_PTR uIdSubclass,
_In_ DWORD_PTR dwRefData
) {
switch (message) {
case WM_QUERYENDSESSION:
shuttingDown = true;
break;
case WM_ENDSESSION:
if (wParam == FALSE)
shuttingDown = false;
break;
case WM_CLOSE:
if (shuttingDown) {
DestroyWindow(hWnd);
// or:
// PostQuitMessage(0);
return 0;
}
break;
case WM_NCDESTROY:
RemoveWindowSubclass(hWnd, AppWndProc, uIdSubclass);
break;
}
return DefSubclassProc(hWnd, message, wParam, lParam);
}
There's no specific message to handle your File>Exit. You must handle it as any other menu item:
Define an identifier for your menu item. Choose anything you want, it has no particular meaning for windows.
When constructing your menu, specifiy this identifier in AppendMenu/InsertMenu/etc. or in your resource file
In your window procedure, intercept the WM_COMMAND message. If LOWORD(wParam) corresponds to the identifier, this means that the menu item has been activated
A typical way of handling an exit command is to send a WM_CLOSE message, as you are already doing in your example code.
So you will avoid code duplication and be sure that the behavior will be the same regardless of how the user choose to exit your application (via menu, click on the "x", or Alt+F4)
In the handing of WM_CLOSE, you can choose to show a message box, destroy the window, post a quit message, or whatever else you want. BY default the DefWindowProc calls DestroyWindow, which in turn sends the WM_DESTROY message.
Note that WM_CLOSE is also triggered when selecting the "Close" item of the system menu (Alt+Space or click on the window icon on the left next to the window title)
I'm working on some CreateWindow things.
My work need I to insert a Button into one of an Application's Window, and when I click the button, my application can do something. That Application isn't my Application, so I think I need to do some "hook thing".
And I tried this:
HWND hwnd = FindWindowEx("className",NULL)
CreateWindowEx(...hwnd...)
Its worked. The Button successfully inserted into target application.
but when I try to handle that window's message
I failed.
This hwnd is belongs to my application hInstance, but my Application has its own message loop by CEF.
I tried SetWindowsHookEx,but its not working.
Whatever I do, it will not handled.
and if i use while(GetMessage (&messages, NULL, 0, 0)),it will block my application's thread
WNDCLASS xxx and RegisterClass(xxx)
or CreateWindow(className)
confused me.
I try to use LRESULT CALLBACK WndProc(HWND hwnd, UINT msg, WPARAM wParam, LPARAM lParam) but the while() will block my application's thread
and in my application's wndProc, there is no WM_COMMAND message in.
HWND hwnd = FindWindowEx(0, 0, L"TCustomBaseForm" , NULL);
HWND hwndButton = CreateWindowEx(0L,_T("Button"), L"Btn", WS_CHILD|WS_VISIBLE| BS_PUSHBUTTON, 435, 45, 35, 45, hwnd, NULL, GetModuleHandle(0), 0);
DWORD dwProcId = 0;
DWORD dwThreadId = 0;
dwThreadId = GetWindowThreadProcessId(hwndButton, &dwProcId);
SetWindowsHookEx(WH_MOUSE, Hookproc, g_hInstance, dwProcId);
Until now, my "inserted button" never work.
So, is there any way to make this "inserted window" or button same as a MFC button that, when I click it, I can handle a message like WM_LBUTTONCLICK in my WndProc?
A button sends a WM_COMMAND message to its parent window when you click it.
There are at least two ways to deal with this without hooking:
Create the button as a child of a STATIC control (or a custom window) that you also create. You need to subclass the STATIC control to receive the message.
Subclass the button and catch the mouse up message and space/enter key-down messages.
Thank you all. I did it.
I create a Window that have a button. And I use SetParent(myWindowHwnd,myTargetWindowHwnd) and handle the button's click event in my window, it works.
No hook, no problems.
Thank you all very much.
And thanks for edit my question, for my poooooooooooor English.
I've learned a lot about Windows Hook.
If I have a console application with a handle to it set up like so;
HWND hWnd = GetConsoleWindow();
Then how do I set up a new wndProc for the window?
I tried using
SetWindowLong(hWnd, GWL_WNDPROC, (LONG)conProc);
With conProc being defined as
LRESULT CALLBACK conProc(HWND hWnd, UINT msg, WPARAM wParam, LPARAM lParam)
{
switch(msg)
{
case WM_NCHITTEST:
return HTCAPTION;
}
return DefWindowProc(hWnd, msg, wParam, lParam );
}
But it doesn't work and says "Error code: 5 - Access is denied" on GetLastError()
I understand that it's pretty difficult to modify the console application like this, since it's a csrss.exe application and all, but I'd still like to try..
Thanks.
While the impression is that console window belongs to your process (like other window), it is in fact hosted by CSRSS system process and its WndProc is there. This makes you unable to subclass the window and provide your own WndProc living in your process.
Some related reading:
The process that is in charge of displaying the GUI windows in which consoles are presented is... CSRSS
SetWindowsHookEx with WH_KEYBOARD doesn't work for me, what do I wrong?
Subclassing XP Console Window
First of all SetWindowLong is superseded by SetWindowLongPtr, you should use that function.
Are you trying to change the WNDPROC of your own console window or another process?
From the MSDN docs :
GWL_WNDPROC
-4
Sets a new address for the window procedure.
You cannot change this attribute if the window does not belong to the same process as the calling thread.
I know the way window is created when the app is windowed one from the start, that is you call
LRESULT CALLBACK WindowProc(HWND hwnd, UINT msg, WPARAM wparam, LPARAM lparam);
int WinMain(HINSTANCE hInst,HINSTANCE,LPSTR,int nCmdShow);
But what to do if I want to get user an option to display a console application output when it ends. That is display its data in more readable form in ad-hoc created window instead of text-only mode that console permits.
In console app I have a function that watches for user key press, and when my program ends it shows message: press D to display result in a window instead of console, and in code:
if (virtual_key == 0x44) {
HWND myWindow = myCreateWindFunc(/* data */);
}
That is I need to pack all the code for creating window into one function an then just call function on it with the data to fill it's controlls.
A console application can create child windows or dialog boxes using any related WinAPI function (MessageBox, DialogBox etc).
The only caveat is that the create function may require the handle of the console window. To obtain it, you could use the example here How To Obtain a Console Window Handle
if i close my application via Alt-F4, or the corner "X" button, or by posting destroywindow(hwnd) myself, the application closes correctly, and everything works just as expected.
but recently i realized, on windows7, when i close the app by right klicking on the icon in the taskbar, and clicking "Close Window", the window closes, but my app is still running. when debugging, i don't get into either of the WM_QUIT/DESTROY/CLOSE events.
is there some special behavior when closing a window via taskbar? how can i detect that?
You should get WM_CLOSE. Maybe you're getting it on a different window that the one you're expecting? Although that shouldn't be able to happen unless you have multiple top-level windows.
via Alt-F4, or the corner "X" button, or by posting destroywindow(hwnd) myself
You can't post DestroyWindow(). Ensure that the window procedure of your main window resembles this:
LRESULT CALLBACK WndProc(HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam)
{
switch (message)
{
case WM_DESTROY:
PostQuitMessage(0);
break;
// Other cases
//...
default:
return DefWindowProc(hWnd, message, wParam, lParam);
}
return 0;
}
The PostQuitMessage() function call ensures that your message loop exits, GetMessage() returns FALSE when it receives the WM_QUIT message. This makes your main window behave like the main window, closing it ends the process. You may have other top-level windows that don't, they shouldn't have this WM_DESTROY message handler. DestroyWindow() is already called automatically by DefWindowProc() when it processes the WM_CLOSE message.