Windows is a "message based", multitasking operating system. Multitasking means that you can have more than one application running at a time and "message based" (also referred to as "event driven") means that while an application is running, it is simply sitting in memory dormant, waiting for event messages to be sent to it by the operating system or from another running application. When you press a key on your keyboard or click your mouse, you are generating events. At the moment an event occurs, the operating system sends a message describing the event to the application that is the target of the event (i.e. the top level window for keyboard and mouse events). Messages are sent by writing them to a message "queue" for the application. When the system is idle (i.e. no programs are busy doing anything), Windows passes control to each running application in turn to give it a chance to process any event messages that it finds in its message queue. When the application is finished processing all of its messages it passes control back to the operating system so that the next running application can process its event messages. The important point here is that while one application is busy doing something, all other applications are unable to process any of their own event messages until the first application finishes.

DDE is simply a way for one application to send messages directly to another. When one program passes data or sends a DDE command to another it is simply sending a message that will get placed in the other application's message queue. The receiving application will not be able to act on that message until the sending program goes idle thus allowing it to process its messages.

If you understand what is going on behind the scenes, you can avoid some common mistakes. For example, suppose you have a device that responds to a prompt sent via the serial port. When the device receives the prompt it sends back a string of data. You also want to write an Excel macro that will send a command to the Wedge causing it to send the prompt out the serial port and then you want Excel to read the response back from the device by performing a DDERequest to the Wedge. You might come up with the following Excel macro that, although it appears to be quite logical, will never work.

The reason the above subroutine will not work is because the DDEExecute statement only sends a message to the Wedge. The subroutine does not relinquish control and let the Wedge process the message until it reaches the "End Sub" statement. The DDERequest that follows the DDEExecute statement is asking for data that will not be available until the Wedge gets a chance to run; i.e. after this subroutine has finished executing.