Thanks Joseph M. Newcomer [MVP] for your help.
"Joseph M. Newcomer" <newcomer@flounder.com> wrote in message
See below...
On Tue, 16 Jun 2009 10:31:33 +0800, "Sunny" <sound_of_nature@hotmail.com>
wrote:
See below.
"Seetharam" <smisro@gmail.com> wrote in message
news:b1b5671b-f0db-4a9d-8579-b22d16c260de@d25g2000prn.googlegroups.com...
Show us some code.
I just tried this *test* in a sample MFC MDI app. It works OK.
void CtestAppApp::OnAppAbout()
{
CMainFrame* pMainFrame = (CMainFrame*)AfxGetMainWnd();
CWnd* pFrame = pMainFrame->GetActiveFrame();
pFrame->ShowWindow(SW_HIDE);
CAboutDlg dlg(pFrame);
dlg.DoModal();
}
-Seetharam
The detail is that i also write a IE addin which provides some interfaces
invoked by the Web application.
****
I keep wondering how it is that critical information like this doesn't get
presented in
the original question...
****
And the IE addin needs the sdi application be started so that the IE addin
can do some commucations with the sdi application.
So i create a event by calling CreateEvent function in the interface of
the
IE addin,
then i call CreateProcess to start the sdi application,
after calling the createprocess function i call WaitForSingleObject to
wait
the hCheckCompleteEvent is signaled. then i can do some things .see below.
BSTR CAddin::setData(LPCTSTR astrParam)
{
HANDLE hCheckCompleteEvent =
CreateEvent(NULL,FALSE,FALSE,_T("26E440F6-0535-4e36-BC77-8482940535E4"));
STARTUPINFO si;
PROCESS_INFORMATION pi;
ZeroMemory( &si, sizeof(si) );
si.cb = sizeof(si);
si.wShowWindow = SW_HIDE;
ZeroMemory( &pi, sizeof(pi) );
if(CreateProcess(_T("c:\\sdi.exe"),NULL,NULL,FALSE,NULL,NULL,NULL,&si,&pi))
****
I presume this path is illustrative, rather than actually in the code
(note that in many
sites, it is impossible to put files in the root directory, because of how
security is
configured)
****
{
CloseHandle( pi.hProcess );
CloseHandle( pi.hThread );
}
DWORD waitRt = WaitForSingleObject(hCheckCompleteEvent ,10000);
if (waitRt==WAIT_OBJECT_0)
{
//do somethings.
}
*****
And if it times out? What happens then? There is only ONE correct way to
handle this:
switch(WaitForSingleObject(...))
{ /* wfso */
case WAIT_OBJECT_0:
break;
case WAIT_FAILED:
ASSERT(FALSE);
...get out.... (return, return false,
or something
like that)
case WAIT_TIMEOUT:
...deal with timeout
...and don't break;
default:
ASSERT(FALSE);
...deal with failure
} /* wfso */
I find it hard to deal with code that tests ONE of the potential FOUR
return values
(actually, three, because WAIT_ABANDONED won't happen for an Event) and
assumes that any
other value must be the expected one...
Or, as I tell my students, if you put a timeout in, you had Better Have A
Plan.
*****
}
While the application is starting. i start another thread (here we call
it
WorkThread) to do somethings. some codes like below.
UINT WorkThread(LPVOID lParam)
{
CMainFrame *pFrame = (CMainFrame*)lParam;
//do somethings
HANDLE hEvent = CreateEvent(NULL, FALSE, FALSE,
_T("CAE80711-F161-4fd7-87A9-3CB354A87A96"));
*****
If this event is used entirely within this app, you should not give it a
name. I note
that you have not made provision in the preceding code for what happens if
two or more
instances of the app are invoked.
*****
LRESULT lRet =
pFrame->SendMessage(WM_SHOW_MODAL_DIALOG,(WPARAM)hEvent );
*****
NEVER, EVER name user-defined messages with WM_. It is poor practice.
Create your own
prefix; if you can't think of one, UWM_ and WMU_ are popular.
And don't use SendMessage between threads. Use PostMessage!
*****
WaitForSingleObject(hEvent, INFINITE);//wait for the dialog is showed
*****
Since you used SendMessage, you won't return until the dialog is
displayed. So why
bother?
*****
CloseHandle(hEvent);
HANDLE hCheckCompleteEvent =
CreateEvent(NULL,FALSE,FALSE,_T("26E440F6-0535-4e36-BC77-8482940535E4"));
*****
Generally, when using a GUID for cross-process objects (which is Best
Practice), you
should put a human-readable string in front just to indicate what is going
on. Since you
have two GUIDs here, that makes the code immediately unreadable without
the prefix. Also,
have you heard of "header files"? The name, if shared between two
applications, should
have a symbolic name (such as a #define or something else suitable as a
const) and both
applications share the header file.
*****
if (hCheckCompleteEvent !=NULL)
{
SetEvent(hCheckCompleteEvent );//set the hCheckCompleteEvent be
signaled so that the addin can be waken.
CloseHandle(hCheckCompleteEvent );
}
}
//call this function when the application start.
void CMainFrame::OnStartup(WPARAM wParam, LPARAM lParam)
{
//do somethings...
AfxBeginThread(&WorkThread, this);
// do other things.
}
LRESULT CMainFrame::OnShowModalDialog(WPARAM wParam, LPARAM lParam)
{
//do somethings...
CModalDialog dlg(AfxGetMainWnd());
dlg.DoModal();//The problem is here. the dialog is visualable ,but i
can
do nothing with it, it seems die there ( there is't any long computation
is
doing in the CModalDialog).
HANDLE hEvent = (HANDLE)wParam;
if(hEvent )
SetEvent(hEvent);//make the event signaled.
****
Note that because you used SendMessage, the SendMessage does not return
until the dialog
closes, so the thread remains blocked.
Note that blocking the thread in IE is probably high in the list of
Really, Really, Really
Bad Ideas. So I find the whole design suspect. All of IE is going to be
blocked while
this app runs. You are making one of the most common errors in program
design: trying to
force synchronous behavior onto an asynchronous system. This is usually
doomed. IE
should just launch the process and forget about it, unless the process
sends some
interesting notification to IE (via a Registered Window Message that you
are prepared to
handle). And if you say "but the page HAS to wait until the process
finishes" I get even
more nervous. Trying to force sequential behavior between processes is
just a losing
idea, big time. It means the design is probably wrong. If IE has to
"wait", then the
correct behavior is to simply disable appropriate controls until an
asynchronous
notification is received.
joe
****
return dlg.state;
}
The problem happened when i PostMessage to the main gui thread to show the
popup modal dialog(the main gui window is created and hided). the popup
modal dialog is visualable ,but i can do nothing with it.
i don't know why?
****
Thanks.
Best regards.
Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm