C / C++ / MFC

DWORD __stdcall EditStreamCallback(DWORD_PTR dwCookie, LPBYTE pbBuff, LONG cb, LONG *pcb)
{
   LPCWSTR a = LPCWSTR(pbBuff);
   if (dwCookie == 100)
   {
      // pbBuff[0] to pbBuff[cb-1] contain the text of the rich-edit control.
   }
   return 0;
}

void CMyDlg::OnBnStreamOut()
{
   EDITSTREAM es = { 100, 0, &EditStreamCallback };
   rich_.StreamOut(SF_TEXT, es);
}

EvScott wrote:

I'm not using a dialog box, I'm using CreateWindow to draw my controls.

// For storing the edit control's original wndproc
WNDPROC wpOrigEditProc;

// The sub-classed edit control's wndproc
LRESULT APIENTRY EditSubclassProc(
                                  HWND hwnd, 
                                  UINT uMsg, 
                                  WPARAM wParam, 
                                  LPARAM lParam) 
{ 
   // Increment the key code for a WM_CHAR message
   if (uMsg==WM_CHAR) 
      ++wParam; 

   // Pass all messages on to the original wndproc. Obviously, the WM_CHAR one has been tampered with :-)
   return CallWindowProc(wpOrigEditProc, hwnd, uMsg, wParam, lParam); 
} 

// The main window's wndproc - I've not shown all of it, just the bit that interacts with the edit control
LRESULT CALLBACK WndProc(HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam)
{
   int wmId, wmEvent;
   PAINTSTRUCT ps;
   HDC hdc;

   switch (message)
   {
   case WM_CREATE:
      // Create the window
      editWindow = CreateWindow(_T("EDIT"), _T("edit"), WS_CHILD|WS_BORDER, 10, 10, 300, 300, hWnd, 0, hInst, 0);
      // Sub-class it
      wpOrigEditProc = (WNDPROC) SetWindowLong(editWindow, GWL_WNDPROC, (LONG) EditSubclassProc); 
      // Show it
      ShowWindow(editWindow, SW_SHOWNORMAL);
   break;

// the rest of the WndProc follows here

EvScott wrote:

It doesn't like the hInstance parameter as I have created my Edit and command button windows in the WinMain

softwaremonkey wrote:

shared between several threads

softwaremonkey wrote:

using a mutex

softwaremonkey wrote:

At present, I only need to lock the mutex once before accessing all data members, then release the mutex

struct S
{
   S() { InitializeCriticalSection(&myDataLock); }
   ~S() { DeleteCriticalSection(&myDataLock); }

   void Lock() { EnterCriticalSection(&myDataLock); }
   void Unlock() { LeaveCriticalSection(&myDataLock); }

   int GetData() { Lock(); int i(data_); Unlock(); return i }
   void SetData(int i) { Lock(); data_ = i; Unlock(); }
private:
   // Don't want to be able to copy it...
   S(S const&);
   S& operator=(S const&);
   CRITICAL_SECTION myDataLock;
   int data_;
};

Stuart Dootson wrote:

I believe that if a thread has ownership of a critical section, it can request ownership again and it gets it without delay

softwaremonkey wrote:

This is true, but if we call lock() and unlock() within the Get/Set methods then we reliquish ownership

S s;
s.Lock();
s.SetData(1234);
s.Unlock();

Stuart Dootson wrote:

I should emphasise that I'm pretty sure that's how critical sections work

Stuart Dootson wrote:

I'd validate that belief before relying on it

led mike wrote:

Absofreakinlutly!! Of course fraking microsoft keeps hiding that information in the documentation[^]