Just to let you know that you aren''t crazy null... I reiterate, I have the exact same thread problem as you.
If that thread is just the app, then why(at least in my case) if I exit within the first 10 seconds or so do I get this:

The thread 0xFFFAB9C3 has exited with code -1 (0xFFFFFFFF).
The program ''D:\Ourcon\Version 2.1\Debug\Ourcon.exe'' has exited with code 0 (0x0).

If I wait till after the thread has exited in my program(about 15 seconds, which is signified by a slight stutter in the program), I get this:
The thread 0xFFFAB9C3 has exited with code 0 (0x0).
The program ''D:\Ourcon\Version 2.1\Debug\Ourcon.exe'' has exited with code 0 (0x0).

I''m not sure if this is the same problem you are talking about, but I get it too, and I don''t know how to solve it.
Lotan

null_pointer: Did you check the OLE/COM option when creating the MFC app in AppWizard? The COM support often creates an additional thread to synchronize calls from components in a different COM apartment (but I am not sure if MFC does this by default).

Check if you can find any call that looks like COM initialization in you InitInstance() -- maybe something like AfxOleInitialize(). If you don''t need COM support, you can get rid of that call and maybe the extra thread will go away.

Cheers!

Stoffel: I'll send you the source to my program (not the sample app) and you can see it for yourself, if you want. In the sample app, the thread and the process always exit at the same time -- I was just saying that there's two debug messages in the debug window, and sometimes they give different exit codes (though not from the sample programs, apparently). In my program, the thread either exits before I've pressed the close button on my main window with exit code 0, or as I explained before, it exits with -1 if I click the close button before the thread ends. I have no idea why this happens.

In my program, I create 4 additional threads, and here's the output:

quote:
The thread 0xFFF76B63 has exited with code 0 (0x0).
The thread 0xFFF561D3 has exited with code 0 (0x0).
The thread 0xFFF55987 has exited with code 0 (0x0).
The thread 0xFFF76D37 has exited with code 0 (0x0).
The thread 0xFFF50AF7 has exited with code -1 (0xFFFFFFFF).
The thread 0xFFF773D3 has exited with code 0 (0x0).
The program 'C:\Program Files\Microsoft Visual Studio\MyProjects\Quest\Debug\Quest.exe' has exited with code 0 (0x0).

There are *gasp* 6 threads counted -- 1 for the process (plus the process's exit message), 4 for the 4 separate threads I create, and 1 for no reason at all. Okay, there's a reason; I just don't know what it is yet. In Spy++, there are also 6 threads listed. In VC, under the Threads listing, there are six threads listed. 5 of those threads have the current function listed -- the other 1 doesn't. When I change to that thread and break, it goes into disassembly. All I can make out from the disassembly is that it calls a thread function and then posts its quit message.

EVERYBODY THINKS I'M MAD!!! (Boris Karloff (sp?) -- Charlie Chan at the Opera)

Chipmunk: No, but thanks anyway.

Thanks!


- null_pointer


Edited by - null_pointer on 3/11/00 11:42:37 AM

Found out why the extra thread was there -- must be part of the DX lib's code because the thread didn't have a function name or source -- just assembly. The thread starts when you call DirectDrawCreateEx. Don't know why, but maybe Chipmunk was right when he said something about COM.

VC++ wasn't doing it behind my back; it was DirectDraw

Thanks!


- null_pointer


Edited by - null_pointer on 3/13/00 3:33:17 PM

THANK BOB!!!

Who''s BOB?

http://www.subgenius.com/