Re: How can I correct MFC focus problem after closing HtmlHelp
window?
On Sep 25, 1:01 pm, "Tom Serface" <t...@camaswood.com> wrote:
That would explain it of course. If the mainframe has the focus and it=
's
the one with the handler then that would make sense. However, if the o=
ther
dialog is a modal dialog that still shouldn't be happening if the dialog =
was
the one that popped up the other window the focus should revert to that
window when the help is closed. Do you have a way to tell when the hel=
p
window is closed? If so, perhaps as a stop gap you could force the foc=
us
back to the dialog?
Tom
"Tom" <tom.mon...@gmail.com> wrote in message
news:b1820d35-ea33-4141-94a7-455f2fb8263c@g6g2000vbr.googlegroups.com...
On Sep 24, 4:55 pm, Seetharam <smi...@gmail.com> wrote:
Is your mainframe still disabled? Or do you see it enabled after you
close your help window?
If the mainframe is enabled, you might want to debug through "...\VC
\atlmfc\src\mfc\dlgcore.cpp" and put breakpoints in all places where
you find a "EnableWindow(TRUE)" and debug.
Also, if you rmodal dialog loses modality, please debug the
"EndModalLoop()" method.
-Seetharam
Once the help window is dismissed, both the mainframe and the dialog
appear to be in an inactive state. However, it appears that the
mainframe has the keyboard focus, which I believe is what allows the
shortcut to work.
I tried to do something like that. Here's the basics
void CMainFrame::OnActivateApp(BOOL bActive, DWORD dwThreadID)
{
CFrameWndEx::OnActivateApp(bActive, dwThreadID);
CWnd* mainWnd = AfxGetMainWnd();
CWnd* popupWnd = AfxGetMainWnd()->GetLastActivePopup();
popupWnd->SetFocus();
}
The problem is that GetLastActivePopup returns the mainframe pointer
on return from the help window, which might be related to the fact
that the mainframe has the focus and not the modal dialog.