Events - Win32 vs MFC apps

[EagleKeeper]

Background
Building emulators for H/W that is delayed 6 months
Using shared memory and events controlling the threads using the shared memory on a Win 7 system

Single class, SharedMemory, creates memory mapped file, maps the buffer and create events.
This class is shared/used by two programs (common code). It builds the memory mapped files and events and code to trigger the events.

Each program has a "receiving thread" that uses a pulsed event when data is available in the shared memory buffer.

When I build both programs with MFC, they are able to talk with each other; raising events and passing data via the memory mapped files.

Then I rebuild one program for Win32 (eventual target is WinCE), going backward from MFC to Win32 is a bitch when having to remap control messages :\, using the same Shared Memory class - code untouched.

Now, the events raised by the MFC app are not being seen by the Win32 app.

Using the debugger, I have a breakpoint after the WaitForSingleObject call to the defined event, m_ghEventRecv. Never gets tripped on the Win32app, yet the MFC equivalent is fine.

Theories!!

static DWORD WINAPI SPI_Thread(LPVOID lParam)
{
   while (true)
   {
      WaitForSingleObject(mySelf->m_SharedMemory.m_ghEventRecv,INFINITE);
      mySelf->OnGas_UI_Message(0,0);
   }
}

 

[brandonb]

How is :

mySelf>m_SharedMemory.m_ghEventRecv

Declared?

Also, make sure INFINITE is the same value in both MFC and Win32. Maybe hard code to -1 or whatever the infinite value is.

 

[EagleKeeper]

How is :

mySelf->m_SharedMemory.m_ghEventRecv

Declared?

Also, make sure INFINITE is the same value in both MFC and Win32. Maybe hard code to -1 or whatever the infinite value is.

HANDLE m_ghEventRecv;

I will check on both HANDLE and INFINITE

Thanks

 

[Schmide]

is this a typo?

mySelf[B]>[/B]m_SharedMemory.m_ghEventRecv

Logical mySelf greater than m_SharedMemory.m_ghEventRecv resolving to 0 or 1

mySelf[B]->[/B]m_SharedMemory.m_ghEventRecv

Pointer mySelf to m_SharedMemory.m_ghEventRecv

 

[EagleKeeper]

is this a typo?

mySelf[B]>[/B]m_SharedMemory.m_ghEventRecv

Logical mySelf greater than m_SharedMemory.m_ghEventRecv resolving to 0 or 1

mySelf[B]->[/B]m_SharedMemory.m_ghEventRecv

Pointer mySelf to m_SharedMemory.m_ghEventRecv

Somehow the copy/paste lost the right facing arrow from myself->
m_SharedMemory is the variable for SharedMemory class.
m_ghEventRecv is the Handle to the Event object.

 

[Markbnj]

Hmm, well the thing is there are an asston of differences between a Win32 program and a MFC program, and a lot of those differences could be affecting an issue like this. You say you "built" for Win32, but of course it's not that easy. Your Win32 program has to have a completely different structure than your MFC program. Where's your message pump, for example?

 

[EagleKeeper]

Message pump for Win32 is the standard WinProc handler shown in a generic Windows programming book from the late 80s early 90s.

The problem is not the message pump, but the creation/detection of user defined events

 

[Markbnj]

Message pump for Win32 is the standard WinProc handler shown in a generic Windows programming book from the late 80s early 90s.

The problem is not the message pump, but the creation/detection of user defined events

Yeah it was just the way you described what I would think of as a port. An MFC program and a Win32 program are two different programs, and it seemed strange to talk of building the same source both ways.

Anyway, events go through the message pump ultimately, but as long as you have a standard getmessage loop then I'm sure that parts all good.