Delaying WM_CLOSE so I can allow threads to exit gracefully

Each of your threads should have an API that sets a boolean (or event or finite state machine status or equiv) that tells the thread that you want it to shut down. Any thread termination logic should really be handled by the thread itself. The thread's normal processing logic should poll the termination request periodically and act accordingly.

When you terminate a thread ungracefully from an external process, you do not give the thread an opportunity to deaccess resources or clean itself up properly. A lot of people kill off threads externally but I consider this flawed behavior.

AlwaysLearningNewStuff wrote:

…there was no saying about dialog box sending message to a worker thread

First of all, you cannot just "send message" to a thread.

The thread you want to "send message" two should define some mechanism to accept message. And the message queue could be as simple as the field accepting only one message (such as "it's time to terminate", "new data is available"). In particular, it should be circular, contain some loop checking message availability on each iteration. It may look like polling and often is, but this is not always the case. In particular, you may develop the mechanism the way to waste zero CPU time for waiting. You can throttle the thread and keep it in a wait state when there are no messages. This can be done using the event object. Please see:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms682655%28v=vs.85%29.aspx[^],
http://msdn.microsoft.com/en-us/library/windows/desktop/ms686915%28v=vs.85%29.aspx[^].

Now, most usual and more or less general communication method would be a blocking message queue which, by the way, may allow you to avoid locking of the access to shared data (in short, because event object is itself a thread synchronization primitive). Such queue is one of the main aspects of the producer-consumer problem:
https://en.wikipedia.org/wiki/Producer%E2%80%93consumer_problem[^].

On Windows, one comprehensive approach is offered by Microsoft Asynchronous Agents Library: http://msdn.microsoft.com/en-us/library/dd492627%28v=vs.110%29.aspx[^].

It is possible that, for your purpose, such comprehensive approach would be an overkill. After all, it's possible that you may solve your problems with sending a "message" in only one instance (but you should thoroughly work out the scenario when you send a new message when the previous one is not yet consumed, so you would need to develop a mechanism where new one absorbs the old one). The synchronization would be done via an event object. You may also need locking, which on Windows should be represented by critical section as you want to synchronize the threads only on the same process; and critical section is the most light-weight variant of mutex (please see http://en.wikipedia.org/wiki/Mutual_exclusion[^]).

I would also advise development of a thread wrapper, to encapsulate such things as access and locking inside the wrapper class. This way, you can abstract out access to the thread.

—SA

You seem to be approaching a very complex area of programming with insufficient knowledge.

I read these articles about threads many years ago and have never looked back. They are worth reading. Any time you spend studying these will be well rewarded IMHO.

http://www.flounder.com/workerthreads.htm[^]

The problem of thread termination is well covered in the preceding.

Very hard to give answers that help you to solve to problem because learning multithreading and becoming able to REALLY see behind the curtains requires months if not years in my opinion. There are many different solutions to your problem depending on what you consider acceptable behavior. One of these behaviors that is the simplest to implement was described by Philippe Mori: simply don't let your windows closed when worker threads are present in your system. If this behavior isn't good for you then continue reading this answer but I don't guarantee that you will be able to implement all solutions but at least you will have clue on what is an acceptable and viable solution in your case.

Some basic information about WM_CLOSE before explanation about threads: If someone presses X on your window or dialog then your window receives WM_SYSCOMMAND/SC_CLOSE that is converted into WM_CLOSE (by the DefWindowProc if you dont handle SC_CLOSE directly). If some presses Alt+F4 then your window receives WM_CLOSE directly. Additionally your window can receive directly posted/sent WM_CLOSE message from your code from any threads or from any threads of external processes. WM_CLOSE is nothing more: its like a button press event, you can simply ignore it if you want however that would really break the behavior the users expect. But wait, WM_CLOSE closes/destroys the window, isn't it??? If you don't handle WM_CLOSE or you call the default handler too after your code then DefWindowProc is called with WM_CLOSE where the default behavior is calling DestroyWindow on your window/dialog that you don't want in many cases. In MFC destroying your main window means the termination of your program.
So the conclusion: WM_CLOSE is just a request, a "button press event" that you can ignore and take default behavior depending on the "state of your program" from the perspective of your gui thread. For example many applications use WM_CLOSE to prevent application close when you haven't saved the document, you can use WM_CLOSE to popup a messagebox.

If you don't want your application or maybe your dialog to be closed then just handle WM_CLOSE and instead of calling the default handler (that would destroy the window) you check whether a thread is running and if you found some active worker threads than you take one of the following actions:

EDIT: In all cases immediately send a cancel message/set a (synchronized!!!) cancel flag to singal your thread that it should terminate gracefully as quick as possible! In some cases a thread is not cancellable, in this case skip this step...
After this take one of the following actions:

1. Popup a messagebox that "Sorry, XYZ is still in progress, try again later". This is the easiest solution recommended by Philippe.

2. You may want to implement automatic exit when workers terminate. You can take any action that works only on the state of the gui side, you can always change gui state as you wish on the gui thread. For example after setting the "autoexit flag" you can show a "dialog/panel" that ignores every button/mouse input along with WM_CLOSE with the label: "Exiting", or you can hide all windows: hiding isn't the same as destroying and hiding is also just a gui state change!
OK, we set the autoexit flag and we changed the gui state, whats next??? The autoexit flag and all other gui related variables/states are accessable only from the gui thread. This means that you will need a gui event (like WM_CLOSE and its friends) to handle this autoexit. But what kind of gui event will this be??? You have N worker threads and you have some info from these on the gui side data (accessible fromt he gui thread) even if this data is only the fact that these threads exist and has been started. The best way to solve this event problem in a gui program is sending a message to a window of the gui program from the thread at the end of the threadproc. This can be a simple custom window message for example to the main window like (WM_USER+5). Any worker thread is allowed to use PostMessage or SendMessage (I recommend PostMessage) to send a message to a gui thread (and you can send for example a thread pointer or thread id or whatever as wParam of the message). This way we can handle this message on the gui side and we can update our gui-side data about the threads. When you recieve this thread-finished message you have to take the following actions:
- Wait for the thread to terminate. You have to do this. Since the thread Posted (not Sent!!!) this message from the end of its threadproc this wait wont take long so you gui wont hang up! You have to wait/join every worker thread that you have started (this is the ownership thing, you are in control with this as others mentioned)! Period.
- Since we received this message we know that we have 1 less worker thread. If the number of worker threads have reached zero then lets check the autoexit flag: if its set then you can start program shutdown (that you previous cancelled by handling WM_CLOSE) this way: http://support.microsoft.com/kb/117320[^]

In MFC there are two AfxBeginThread() functions, if you don't want to freeze because of calling some MFC lib funcs or some libraries that make use of MFC libs then use the worker thread version of this AfxBeginThread() functions to create your thread instead of some WinAPI/crt CreateThread/beginthread variants. I recommended the worker thread version because secondary ui threads are useless and they are just a wasting resources.

The only thing you have to do is: dont leave the main message loop until the excel-interface has been released. Is the excel interface used in a thread, please wait until the thread has been terminated. You can delay the main windows close message if you dont delagate the message to the default window proc. The default window proc will destroy the window. Is the thread already running check it and post the message again.

See the following code:

#pragma once
#define WIN32_LEAN_AND_MEAN
#include <windows.h>
#include <tchar.h>

#pragma comment (lib,"user32.lib")
#pragma comment (lib,"ole32.lib")
#pragma comment (lib,"oleaut32.lib")

#pragma warning(disable:4146 4049 4786)
#include "MSO97.tlh"
#include "VBEEXT1.tlh"
#include "EXCEL8.tlh"
#pragma warning(default:4146 4049 4786)

LRESULT FAR PASCAL WndProc(HWND h,unsigned int m,WPARAM w,LPARAM l);

typedef struct
{
  HANDLE    hTerm;
  HANDLE    hThread;

} APPDATA;

int FAR PASCAL _tWinMain(HINSTANCE h,HINSTANCE p,LPTSTR c,int sw)
{
  WNDCLASS  wc;
  HWND      hwnd;
  MSG        m;
  APPDATA    app = { 0,0 };

  wc.style         = CS_DBLCLKS;
  wc.lpfnWndProc   = WndProc;
  wc.cbClsExtra    = 0;
  wc.cbWndExtra    = 0;
  wc.hInstance     = h;
  wc.hIcon         = 0;
  wc.hCursor       = LoadCursor(0,IDC_ARROW);
  wc.hbrBackground = (HBRUSH)(COLOR_WINDOW+1);
  wc.lpszMenuName  = 0;
  wc.lpszClassName = __TEXT("ThreadMain");

  RegisterClass(&wc);

  app.hTerm = CreateEvent(0,0,0,0);
  hwnd = CreateWindowEx
  (
    0,
    wc.lpszClassName,
    __TEXT("Main window"),
    WS_OVERLAPPEDWINDOW,
    CW_USEDEFAULT,
    CW_USEDEFAULT,
    CW_USEDEFAULT,
    CW_USEDEFAULT,
    (HWND)0,
    (HMENU)0,
    wc.hInstance,
    (void*)&app
  );
  if(IsWindow(hwnd))
  {
    ShowWindow(hwnd,sw);
    // message loop
    while(GetMessage(&m,0,0,0))
    {
      TranslateMessage(&m);
      DispatchMessage(&m);
    }
    // if thread is already running
    if(app.hThread)
    {
      SetEvent(app.hTerm);
      WaitForSingleObject(app.hThread,INFINITE);
      CloseHandle(app.hThread);
    }
  }
  CloseHandle(app.hTerm);
  return 0;
}

LRESULT FAR PASCAL ExcelThread(void* p)
{
  HANDLE        hterm = (HANDLE)p;
  HRESULT        hr;
  
  if(S_OK==CoInitializeEx(0,COINIT_MULTITHREADED))
  {
    Excel::_ApplicationPtr    excelapp;

    // start excel
    excelapp.CreateInstance(__TEXT("Excel.Application"),0,CLSCTX_LOCAL_SERVER | CLSCTX_REMOTE_SERVER);
    if(excelapp)
    {
      // show excel
      excelapp->Visible = 1;

      // do anything you want to do with excel
      // but wrap it into try...catch
      // ...................

      // this loop waits until excel is closed
      while(WAIT_TIMEOUT==WaitForSingleObject(hterm,1000))
      {
        /**/ try {
        if(!excelapp->Visible)
          break;
        /**/ } catch(...){}
      }
      // finally on stop thread:
      // bring excel to front
      /**/ try {
      excelapp->WindowState = Excel::xlMinimized;
      excelapp->WindowState = Excel::xlNormal;
      /**/ } catch(...){}

      // close all sheets
      /**/ try {
      while(excelapp->ActiveWorkbook)
      {
        excelapp->ActiveWorkbook->Close();
      }
      /**/ } catch(...){}
      // cleanup
      hr = excelapp->Quit();

    }
    CoUninitialize();
  }

  return 0;
}

// dialog proc
int FAR PASCAL DlgProc(HWND h,unsigned int m,WPARAM w,LPARAM l)
{
  unsigned long    tid;
  APPDATA*        app = (APPDATA*)GetWindowLong(h,DWL_USER);
  switch(m)
  {
    case WM_INITDIALOG: SetWindowLong(h,DWL_USER,(LONG)l); break;
    case WM_CLOSE     : DestroyWindow(h); break;
    case WM_COMMAND   :
      switch(LOWORD(w))
      {
        case 100: // start thread
          if(app->hThread)
          {
            if(WAIT_TIMEOUT==WaitForSingleObject(app->hThread,1))
              break;
            CloseHandle(app->hThread);
            app->hThread = 0;
          }
          app->hThread = CreateThread(0,0,(LPTHREAD_START_ROUTINE)ExcelThread,app->hTerm,0,&tid);
        break;
      }
    break;
  }
  return 0;
}

// tool dialog
void ShowThreadDialog(HWND hParent,APPDATA* app)
{
  HWND            hdlg;
  HINSTANCE        hinst = (HINSTANCE)GetWindowLong(hParent,GWL_HINSTANCE);
  HRSRC            hres = FindResource(hinst,MAKEINTRESOURCE(100),RT_DIALOG);
  HGLOBAL          hmem = hres ? LoadResource(hinst,hres) : 0;

  if(hres)
  {
    hdlg = CreateDialogIndirectParam(hinst,(DLGTEMPLATE*)LockResource(hmem),hParent,DlgProc,(LPARAM)app);
    if(IsWindow(hdlg))
    {
      ShowWindow(hdlg,SW_SHOW);
    }
  }
}

// window messages
void WmCreate(HWND h,APPDATA* app)
{
  SetWindowLong(h,GWL_USERDATA,(LONG)app);
  ShowThreadDialog(h,app);
}

void WmClose(HWND h,APPDATA* app)
{
  if(app && app->hThread)
  {
    // is thread running
    if(WAIT_TIMEOUT!=WaitForSingleObject(app->hThread,1))
    {
      CloseHandle(app->hThread);
      app->hThread = 0;
      DestroyWindow(h);
    }
    else
    {
      // try to stop thread
      SetEvent(app->hTerm);
      // and try it again
      PostMessage(h,WM_CLOSE,0,0);
    }
  }
  else DestroyWindow(h);
}

// main window proc
LRESULT FAR PASCAL WndProc(HWND h,unsigned int m,WPARAM w,LPARAM l)
{
  APPDATA*  app = (APPDATA*)GetWindowLong(h,GWL_USERDATA);
  switch(m)
  {
    case WM_CREATE       : WmCreate(h,(APPDATA*)((CREATESTRUCT*)l)->lpCreateParams); break;
    case WM_CLOSE        : WmClose(h,app); return 0; // do not call the default proc
    case WM_DESTROY      : PostQuitMessage(0); break;
  }
  return DefWindowProc(h,m,w,l);
}

Good luck.