Printable View
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?
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
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
Sorry, I have no idea because I never worked (so tightly) with ActiveX.
Try to search in Google Groups for such a problem
Here's how I override WM_GETDLGCODE (in Win32):
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.Code: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;
}
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.:
Code: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);
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
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
Ok I found one site that showed me a little light for this topic:
http://blogs.msdn.com/oldnewthing/ar...30/201988.aspx
Oh, YES! :wave:Quote:
Originally Posted by vlko
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