endless messages WM_GETDLGCODE when focus is lost

[KellyLynch]

I have an ActiveX component (it contains several child windows). I put the component into usual modal dialog (MFC 4.2). The following problem appears: when input focus is located in one of fields of the ActiveX, I press Alt-Tab to go to another application. Since this moment my programs hangs over because of endless messages WM_GETDLGCODE. They come to the child window of the ActiveX where the focus was located before leave.

How may I fix the problem?

[vlko]

I have the same issue!

Has someone any idea what can be the problem? Please.

My Window structure is:

MainAppWindow
MDIClient
Dialog
ActiveX (VB6) as container
SSTab (VB6)
.NET Interop UserControl as ActiveX

When I click on button in Dialog window new dialog is opened. When I close it, and click on one of the inner controls (i.e. TextBox) in the .NET Interop UserControl it will jump into infinity loop raising WM_GETDLGCODE message (as seen in Spy++). The message problem is in ActiveX (VB6).


Thanks.

Michal

[VictorN]

Not sure there might be your case(s):
KB179696
KB177103

[vlko]

Thank you for fast answear Viktor.

That KB articles looks similar but I have problem with Click event. I'm not pressing any key when I'm trying to focus inner TextBox control.

What I already tested is, that when I will close that dialog and click firstly on SSTab (so I will focus it) and after I will click into .NET Control (into it's textbox) everyting works and no WM_GETDLGCODE is generated.

I'm resolving it for 2 weeks already, and I'm realy out of ideas how to fix it.

Is there a way to correctly return from WM_GETDLGCODE message? I was trying to override wndproc of that VB6 ActiveX and handle that WM_GETDLGCODE message. But whatever I returned, it was always endless loop.

Michal

[VictorN]

Sorry, I have no idea because I never worked (so tightly) with ActiveX.
Try to search in Google Groups for such a problem

[Martin O]

Here's how I override WM_GETDLGCODE (in Win32):

	case WM_GETDLGCODE: {
		LRESULT result = CallWindowProc(oldproc, hWnd, msg, wParam, lParam);

		MSG *m = (LPMSG) lParam;
		if(m) {
			if(m->wParam == VK_ESCAPE) return result | DLGC_WANTALLKEYS;
			else if(m->wParam == VK_RETURN) return result | DLGC_WANTALLKEYS;
		}
		return result;
	}

If I remember correctly, this was used in a subclass of an edit control where I wanted to override the default behavior of enter and escape.

I've seen endless or infinite WM_GETDLGCODE before...I checked some old code I have of a custom control (not active x) where I had to mess with tab order to prevent it. Here it is...not sure if it will apply in your case. This is code from a WM_CREATE handler for a custom grid control. I'm creating a dummy control to workaround the infinite loop problem.:

case WM_CREATE:
...

	// Create a non-visible 'ENDGROUP' static control, and put tabposition of main grid ctl after it
	// This is to fix problem of infinite loop of WM_GETDLGCODE messages with WS_GROUP & WS_EX_CONTROLPARENT & radio buttons.
	// Problem was that adding radio buttons would cause a hang - something to do with the dialog-keyboard logic.
	// This solution puts a non-WS_EX_CONTROLPARENT control ('ENDGROUP') before the main grid ctl window with a WS_GROUP style.
	// This seems to cause the dialog-keyboard logic to stop before the WS_EX_CONTROLPARENT control.
	// NOTE: there is a little wierdness because a child window (ENDGROUP) has a tab position before its parent
	//		 (the main grid ctl window) Hopefully this isnt a problem. If it is, then ENDGROUP would have to be a sibling
	//	     of gridctl and gridctls WM_DESTROY handler would have to destroy ENDGROUP
	HWND h = CreateWindowEx(0, "STATIC", "ENDGROUP", WS_CHILD | WS_GROUP, 0, 0, 0, 0, hWnd, (HMENU) NULL, lpcs->hInstance, (LPVOID) NULL);
	SetWindowPos(hMyCustomControlWnd, h, 0, 0, 0, 0, SWP_NOMOVE | SWP_NOSIZE);

[vlko]

First of all, that you for your post it. I will try new things.
My issue here is that I cannot handle WM_CREATE message in ActiveX, because I can hook to wndproc only after Initialize method is called on the OCX. And it is VB6 stuff .

Michal

[vlko]

Good news I solved it

The issue was, that ActiveX didn't had EXSTYLE WS_EX_CONTROLPARENT. I don't know background about this style but after adding this style through SetWindowLong() .NET Control gets focus and doesn't freeze anymore.

That style stoped WM_GETDLGCODE flooding.

For me it's a mistery solution, but works!

Thank you to all people that wanted to help me.

Michal

[vlko]

Ok I found one site that showed me a little light for this topic:

http://blogs.msdn.com/oldnewthing/ar...30/201988.aspx

[VictorN]

Good news I solved it

The issue was, that ActiveX didn't had EXSTYLE WS_EX_CONTROLPARENT.

Oh, YES!
Now I remember, I hadthe similar situation about 7 years ago but with a child control on the modeless property page:
PRB: Child CPropertySheet Hangs If Focus Is Switched