Interprocess Communication

Windows has always had a variety of ways for programs to communicate with each other. Fashions change. Here’s what’s in and what’s out in Visual Basic interprocess communications:

• ActiveX components are hot. They are the most convenient way to share data and code inside your own process, across processes, and even across machines.
  
  
• DDE (Dynamic Data Exchange) is out of fashion. It is still supported for compatibility, and Visual Basic still supports it as fully as in previous versions. But this technology has reached a dead end and will never be enhanced.
  
  
• A Remote Procedure Call API exists for calling procedures on different machines. I’ve never used this API, and I can’t think of a good reason to do the hard way what DCOM makes easy.
  
  
• Drag and Drop is cool. In fact, the new form of it, using the OLEDrag­-
  Mode and OLEDropMode properties, is such an easy way to allow a
  user to trans­fer data between programs that it’s not Hardcore and thus didn’t make it into this book.
  
  
• ActiveX hasn’t done anything to invalidate the Clipboard, which is still an effective way to make data from your program available to other programs and to use data made public by other programs. If you’re supplying the data, the problem is letting other programs know it’s there. If you’re receiving the data, the problem is knowing when useful information is available.
  
  
• AppActivate and SendKeys provide a convenient way to activate another program and send it keystrokes. For example, you can send keystrokes to the other program to make it paste from the Clipboard. SendKeys is
  a Visual Basic implementation of the more general technique mentioned in the following item.
  
  
• You can easily send Windows messages to another program with SendMessage or PostMessage. You might expect to be able to receive messages using callbacks accessed through the AddressOf operator. Good luck. The messages you capture will return foreign pointers from another address space. There’s a lot more work involved in cross-process­ messages. Fortunately, the MessageBlaster control supplied with this book does it for you. On the other hand, there’s a good reason why 32-bit Windows keeps pointers in separate address spaces. You might want to think twice before trying to get around those limitations.
  
  
• Win32 adds an important new message, WM_COPYDATA, that allows you to send chunks of data from one program to another. Copying data is more complicated than you might expect. All data resides at ­addresses in memory, but each program has a different address space and can’t understand anything about data in another program’s address space. The WM_COPYDATA message hides the details of getting data from your address space to the address space of another process. Internally, the WM_COPYDATA message uses memory-mapped files.
  
  
• You can share data between processes with memory-mapped files. I’ll show you an example shortly.
  
  
• The Win32 file notification APIs allow you to monitor file events in other processes (or in your own process). I’ll show you this one, also.

Let’s take a look at two of the more interesting techniques for interprocess
communications.