Hey guys, I'm new to this forum so nice to meet you all :D

I'm really bugged by a weird bug that prevents my dialog from showing up, however the buttons show up twice, one overlapping the other. I saw other threads that discusses about this but I'm afraid I can't find a way out through them.

I have already found the problem ( i hope) and (sort of) fixed itby copying and pasting the DialogProcedure code from winprog which i have used as my reference for the project.

here's the code from winprog:

BOOL CALLBACK AboutDlgProc(HWND hwnd, UINT Message, WPARAM wParam, LPARAM lParam)
{
	switch(Message)
	{	
		case WM_INITDIALOG:

		return TRUE;
		case WM_COMMAND:
			switch(LOWORD(wParam))
			{
				case IDCANCEL:
					EndDialog(hwnd, IDCANCEL);
				break;
			}
		break;
		default:
			return FALSE;
	}
	return TRUE;
}

and here's mine:

BOOL CALLBACK CalculatorProc(HWND hwnd, UINT message, WPARAM wParam, LPARAM lParam)
{
	switch (message)
	{	
		case WM_INITDIALOG:

		return TRUE;
		case WM_COMMAND:
			switch (LOWORD(wParam))
			{
			case ID_CANCEL:
				EndDialog(hwnd,ID_CANCEL);
				break;
			}
			break;
	}
	return TRUE;
}

i tried replacing my codes for the WinMain and WinProc on the tutorial's solution and the dialog still worked finely. The difference appeared when i replaced my dialog procedure with the tutorial's. When i pasted the tutorial's procedure, I only changed the name of the variables to match mine, in the end, it completely matches mine. Is there something i missed or am i going blind? :(

Dani AI

Generated

Quick diagnosis and practical checklist for the symptom described by (modal DialogBox doesn't appear but controls show up twice/overlapping): the two most common causes are (1) the dialog resource was built with "child" window styles so its controls are getting created as children of the main window instead of the dialog, and (2) the dialog procedure's return semantics are wrong (returning TRUE for every message suppresses default dialog handling and can produce odd painting/parenting results).

Concrete things to check (do these in order):

  • Resource template styles: open the dialog in the Resource Editor and verify the dialog is a Popup/dialog (WS_POPUP / DS_MODALFRAME / DS_SETFONT), not a WS_CHILD. A child-style dialog will cause controls to appear attached to the parent window and produce the “double” controls symptom.

  • Control/ID collisions: noted the button is ID_CANCEL. Confirm in resource.h that ID_CANCEL isn’t numerically colliding with other controls in the main window. Try using the standard IDCANCEL or a unique ID to rule out a collision.

  • DialogProc return rules: the dialog proc must return TRUE only for messages you handled and FALSE when you want DefDlgProc to do default work. In particular, return FALSE for unhandled messages; for WM_INITDIALOG return TRUE only if you want Windows to set the default focus (otherwise return FALSE after manually setting focus). Failing to do this can suppress default processing that sets up controls correctly.

  • Dialog creation call and ownership: DialogBox(hInst, MAKEINTRESOURCE(...), hParent, dlgProc) is correct for modal dialogs. ’s CreateDialog suggestion is valid for modeless dialogs (CreateDialog returns an HWND which you must keep); switching to modeless changes the ownership/creation semantics and is a different workflow.

  • Debugging: use Spy++ (or EnumChildWindows/GetParent at runtime) to confirm the dialog class is “#32770” and to see each control’s parent window. If a button’s parent is the main window, the template or IDs are wrong.

If copying the tutorial proc fixed the bug earlier, the likely tiny difference was the default return value or an accidental edit in the original proc; a side‑by‑side diff of the two procs usually exposes that. Cleaning/rebuilding the resources after fixing the template/IDs often removes lingering artifacts.

Recommended Answers

All 6 Replies

sorry for double posting, I forgot to mention that i created the dialog in resource view. the dialog is called IDD_DIALOG1 whereas the dialog button is ID_CANCEL :)

If you created the dialog using the CreateDialog function the last function argument should be a pointer to the callback function CalculatorProc.Don't forget to modify that too.

hmm I didn't create using CreateDialog function. I used DialogBox function instead. here's what I did in my WinProc:

LRESULT CALLBACK WinProc(HWND hwnd, UINT message, WPARAM wParam, LPARAM lParam)
{

	switch (message)
	{
	case WM_DESTROY:
		PostQuitMessage(0);
		break;

	case WM_COMMAND:
		{
			switch (LOWORD(wParam))
			{
			case ID_HOME_KELUAR:
				PostQuitMessage(0);
				break;

			case ID_KALKULATOR_KALKULATOR:
				{
DialogBox(GetModuleHandle(NULL),MAKEINTRESOURCE(DLG_KALKULATOR),hwnd,CalculatorProc);
				}
				break;
			}
		}
		break;
	default:
		return DefWindowProc(hwnd,message,wParam,lParam);
	}

	return 0;

}

Try creating a modeless dialogbox.

LRESULT CALLBACK WinProc(HWND hwnd, UINT message, WPARAM wParam, LPARAM lParam)
    {
    static hwnd Dialog; 
    switch (message)
    {
    case WM_DESTROY:
    PostQuitMessage(0);
    break;
     
    case WM_COMMAND:
    {
    switch (LOWORD(wParam))
    {
    case ID_HOME_KELUAR:
    PostQuitMessage(0);
    break;
     
    case ID_KALKULATOR_KALKULATOR:
    {
    Dialog=CreateDialog(GetModuleHandle(NULL),MAKEINTRESOURCE(DLG_KALKULATOR),hwnd,&CalculatorProc);
    }
    break;
    }
    }
    break;
    default:
    return DefWindowProc(hwnd,message,wParam,lParam);
    }
     
    return 0;
     
    }

Thanks for pointing that out, I'll eventually try out the modeless dialog, however, for this project I'd like to use modal. I want to know where I went wrong with my code :( I don't see any difference with my dialog procedure with the tutorial's that could make my dialog not appearing like it is supposed to @.@

I think you must have a static handle of the dialog box otherwise it get's destroyed.The DialogBox does not return a HWDN so i suggested using CreateDialog instead. Just a hunch .. it think it is much like when you declare a child window in a window procedure.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.