Interprocess Communication
There doesn't seem to be a lot of success out there using vb6 for reliable interprocess communication. I've found a few web pages, articles, and tips that give some clues as to how this could be done, but none seem to have crossed the bridge between theoretical/experimental, and actual user-quality messaging between vb6 applications.
I've developed a host application that fires refresh events in 3 client applications, each running in their own thread. These 3 independent threads report back (via windows messaging) when their refreshes are complete, allowing the host application to summarize the "system" status for the user, and sequence the refresh operations to avoid invalid operating states.
Sound simple? I thought it would be. Turned out that it was unreliable. There was one missing link. Here it is.
Microsoft provides vb6 programmers with postmessage and peekmessage procedures, and encourages the programmer to designate message constants above WM_APP so that there is no risk of competing with messages that Windows might be sending, e.g. mouse moves or keyboard clicks. So you'd think that if you post a message at or above WM_APP, you could count on it being in the message queue of the receiving application when you go to look for it. Well, if that receiving application has a DoEvents in it, it might be gone. DoEvents is roughly the equivalent of running an indiscriminate PeekMessage/TranslateMessage/DispatchMessage trio with a Sleep(0) thrown in to give up the remaining time slice. If you watch for messages in an endless loop in your client application, and you put a DoEvents in your loop, DoEvents will throw away your WM_APP message if it gets to it before your WM_APP-specific PeekMessage. Result: only *some* of your WM_APP messages get through to your receiving applications WM_APP processing code. Your messages are not reliable.
Solution: replace DoEvents with the equivalent code (peek/translate/dispatch/sleep), and set this pseudo-DoEvents peekmessage call to only process messages below WM_APP. Since your other peekmessage in your loop will watch for messages at WM_APP or above, you've got the whole message range covered, once, with no overlap. Now your message receiving loop catches *all* the WM_APP messages you send it. Your WM_APP messages always get through.
Until I posted this tip, here, everybody else on the web who claims to be an authority on this subject is just using the standard DoEvents call and is presumably putting up with the occasional lost message. What's up with *that??*
