Re: Stay resident dll

In principle, each thread that wishes to have its own GUI needs a
message queue processor to pump messages to the controls.

Every EXE has a main thread and every GUI EXE has a message queue
associated with the main thread to draw things.

So if you have secondary threads to do background processing, in my
design experience there were two safe ways to pass "data" that is
going to be drawn in the main thread GUI window:

1) Using SendMessage/PostMessage:

The secondary thread calls SendMessage() (send/wait) or PostMessage()
(send/no wait) to the Main thread Message Queue. Here you have to
create some "buffer" to pass via the Send/PostMessage().

If you call SendMessage() which is a SEND/WAIT for completion, you can
  pass a pointer to the local buffer and use it in the main thread
because it will still be "alive" when the main thread gets it.

If you call PostMessage() which is a SEND/NO WAIT, then here you are
queuing the message in main thread message queue to be processed when
the main thread message pump gets to it at some delayed time. So
here, you need to pass a new allocated buffer pointer that the
eventual main thread processing will release.

2) Using a common shared Data Structure.

Here you prepare a common (GLOBAL) data structure filled with fields
and information that:

    1) The secondary thread fills (WRITE)

    2) The main thread via a TIMER or a "WAKE UP" event will
       READ data structure to update "refresh" the screen.

Here you need to synchronize using locks (semaphores, mutexes, etc)
the WRITE/READ of the shared common resource (data structure) to
prevent potential clobbering of data.

For example, lets say you want to data points in the main form window.

       Counter1: ________ << member controls m_Counter1
       Counter2: ________ << member controls m_Counter2

That is updated per threads:

typedef struct _tagCommonData {
     int data1;
     int data2;
} COMMONDATA;

The easiest lock and guaranteed to be CORRECT and SAFE is a Critical
Section but it also the least efficient (speed wise) because its a
mutual exclusive READ or WRITE only operation, never two threads can
access it at the same time which is possible with a concept called
ReaderWriter Locks. ReaderWriter are easy if you get the proper class
from some library.

So you create a global data and critical section:

COMMONDATA globalData = {0};
CCriticalSection csLock();

Now in your secondary threads, your lock and write to the structure:

    MyThread1()
    {
       csLock.Lock(0);
       globalData.data1++;
       csLock.Unlock();
    }

    MyThread2()
    {
       csLock.Lock(0);
       globalData.data2++;
       csLock.Unlock();
    }

Now in your main program, you add a OnTimer() lets say for evert 100
milliseconds.

    MyMainWindow::onTimer()
    {
       csLock.Lock(0);
       m_Counter1 = data1;
       m_Counter2 = data2;
       csLock.Unlock();
    }

You can add some efficiency ideas by only updating if dirty:

    MyMainWindow::onTimer()
    {
       csLock.Lock(0);
       if (m_Counter1 != globalData.data1)
           m_Counter1 = globalData.data1;

       if (m_Counter2 != globalData.data2)
           m_Counter2 = globalData.data2;
       csLock.Unlock();
    }

Instead of a timer, you can consider using a signal like a custom
registered WM_MY_REFRESH message that will call a OnMyRefresh()
message handler in your MyMainWindow to do the screen updating. This
makes it more dynamic if there aren't tons of updating going on.

A Reader/Writer lock allows you to add logic like a Writer Thread puts
a lock on ALL allowing only One writer at a time, but you can have
Multiple Readers as long as they are no active writers. So this an
more efficient than a Critical Section.

So the child threads will enable a Writer Lock:

    MyThread2()
    {
       csReaderWriter.Write();
       globalData.data2++;
       csReaderWriter.Unlock();
    }

and the main thread will use a Reader Lock:

    MyMainWindow::onTimer()
    {
       csReaderWriter.Reader();
       if (m_Counter1 != globalData.data1)
           m_Counter1 = globalData.data1;

       if (m_Counter2 != globalData.data2)
           m_Counter2 = globalData.data2;
       csReaderWriter.Unlock();
    }

The above reader/writer lock example is pseudo code, I don't see a MFC
based Reader/Writer class but there are many in the public domain.

Finally, if you want the child threads to have their own GUI, then the
same and only requirement is that the thread has own message pump.
The same "Inter Thread" communications apply here as with dealing with
the main thread only.

--
HLS

JRGlide wrote: