I have a bit of strange behavior with a MFC application that I haven't seen before. The application is a simple MFC Dialog running unders Windows XP SP3 and using Visual Studio 2008. It builds fine under Debug and Release configurations. The Debug executable runs fine under the debugger and also within Visual Studio using the Start Without Debugging button. The Release executable runs fine directly from Windows. However, the Debug executable does NOT run fine directly from Windows. When double clicked from Windows Explorer, there is a brief hourglass and then what appears to be a quick exit. No messages, no nothing. Adding a few AfxMessageBox calls to the app's CWinAppEx class, it appears that not only does the app's InitInstance method not get called, but even the CWinAppEx constructor does not get called. Obviously, this makes debugging the problem somewhat difficult. Anyone seen similar behavior before? Seems like it might be a manifest problem of some sort, but I don't see why it would only affect the Debug executable and only directly from Windows. Additional Info: With a little more testing, I found that this behavior occurs even in a simple test application as soon as I add any code that requires an internally developed DLL. Note that if I rename this DLL, I get the usual can't find the DLL message. So the app is finding the DLL, but for some reason, in Debug configuration, there's a problem only when running directly from Windows.

Henry Minute wrote:

And somehow, their Calendar went out of synch by about two years. 1914 became 1916 and 1939 became 1941.

No it didn't. We just like to be fashionably late.

modified on Tuesday, September 15, 2009 1:47 PM

Ah... that's quite a bit different than what I was assuming. Thanks for the info.

dan neely wrote:

Still falls well short of the payoff from stealing b4.

Agreed. That was one of the best laid out multiple time travel loop story lines I've ever seen or read.

dan neely wrote:

wmallory wrote: Although I am also rather fond of Carter's quip during the 1st encounter with one of the "old-timer" alien races... Off hand I'm not sure what you're referring to.

IIRC, from memory... Ivanova and Carter on bridge of a Whitestar sitting in space in front of a very large "old-timer" alien spaceship after repeated attempts to make contact. Ivanova: "I don't get it. I know they understand what I'm saying, but they refuse to acknowledge me." Carter: "Oh, so they're French."

Bacon Ultimate Cheeseburger wrote:

CSocket does not create a separate thread.

Are you sure? I was pretty sure it did. OK, I just ran the debugger on one of my programs that uses a CAsyncSocket object. The debugger shows a thread named _SockAsyncThread@4 in the list of threads. Since CSocket is derived from CAsyncSocket, I assumed it would also create a thread.

One of my favorite B5 quotes as well. Not to mention the many episode (almost 2 seasons IIRC) delay between the setup and the payoff. That's a writer with patience. Although I am also rather fond of Carter's quip during the 1st encounter with one of the "old-timer" alien races...

IIRC, MFC CSocket spawns its own thread for handling the data and it is this thread that sends the window messages that trigger CSocket methods such as OnReceive. So in a sense, you are already using a thread. In general, if it works the way you want it to... why change it? Then again, you only used 20 clients to stress test a system that may have thousands. You may still need a better stress test. Although that would be true whether you leave it alone or change to a more direct threaded approach. Just my $0.02.

Did you get your question fully answered by Cedric's response? I couldn't tell from your reply. If not, here's a little code snippet to demonstrate what (I believe) he was suggesting:

CMySpecialDialog MyDialog;

const int Status = MyDialog.DoModal();

if (Status == IDOK)
{
const CString MyString = MyDialog.GetMyString();
}

This will work if you define a GetMyString method in your CMySpecialDialog class. Just remember to keep the string value in a member variable of the CMySpecialDialog class so that it still exists after the return from DoModal. HTH

Visual SlickEdit Gadgets has a SLOC Report as one of the gadgets. I have it working in VS2008. See: http://www.slickedit.com/content/view/441/#SLOCReport[^]