Program remains in memory after ShellExecute

My program launches the default Web browser and quits itself when the users press a button.

::ShellExecute(NULL, NULL, lpszUrl, NULL, NULL, SW_SHOWNORMAL);
this->PostMessage(WM_CLOSE); // I am using MFC, this is the frame window, the only window.

I tested it on Windows 95 with IE 4.01 sp1.

With the Browse in a new process setting of IE enabled:

If there is no IE browser running, pressing the button starts the browser, everything is fine. If there is an IE browser running, pressing the button switches to it with the specified URL, everything is fine except that my program remains in memory (it is there when I press Ctrl-Alt-Del) until I restart the system.

With the Browse in a new process setting of IE disabled:

My program remains in memory from the second time the button is pressed.

I think chensu is expecting the application to post the quite message (PostQuitMessage() when it closes the main window. That is the way most applications work. That is why I'm wondering if the main window closes.

Veeam® is happy to provide a FREE NFR server license to certified engineers, trainers, and bloggers. It allows for the non‑production use of Veeam Agent for Microsoft Windows. This license is valid for five workstations and two servers.

After ShellExecute, the system sends my window the WM_DDE_INITIATE messages and sends another window (don't know where) the WM_DDE_ACK message (On Windows NT, no this message). At this point, if my main window has been closed, the problem comes out. The workaround is to delay for a while after ShellExecute. And only on Windows 95, there is always a First-chance exception in KERNEL32.DLL after the WM_DDE_ACK message no matter whether my main window is closed at that time.

The PostAppMessage function is obsolete in Win32. Win32-based applications should use the PostThreadMessage function. As nietod said, the application posts the WM_QUIT message (PostQuitMessage) when it closes the main window. The application does not receive the WM_QUIT message even if I send it explicitly when the problem described above is there.

The problem is that IE is opening up a DDE conversation with you, but you are exiting before finishing it. Try using ShellExecuteEx with the SEE_MASK_FLAG_DDEWAIT flag, which causes the ShellExecute routine to wait until the DDE conversation has finished.

Featured Post

Create well-organized and polished visualizations of your virtual and backup environments when planning VMware vSphere, Microsoft Hyper-V or Veeam deployments. It helps you to gain better visibility and valuable business insights.

For a while now I'v been searching for a circular progress control, much like the one you get when first starting your Silverlight application. I found a couple that were written in WPF and there were a few written in Silverlight, but all appeared o…

For most people, the WrapPanel seems like a magic when they switch from WinForms to WPF. Most of us will think that the code that is used to write a control like that would be difficult. However, most of the work is done by the WPF engine, and the W…

This is Part 3 in a 3-part series on Experts Exchange to discuss error handling in VBA code written for Excel.
Part 1 of this series discussed basic error handling code using VBA.
http://www.experts-exchange.com/videos/1478/Excel-Error-Handlin…

In this video, Percona Solution Engineer Rick Golba discuss how (and why) you implement high availability in a database environment.
To discuss how Percona Consulting can help with your design and architecture needs for your database and infrastr…