Avoid Common DDE
Programming Errors
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.
Sub PromptMyGizmo()
Chan =DDEInitiate("WinWedge", "COM1")
'open a DDE link with WinWedge
DDEExecute Chan, "[SENDOUT(’?’,13,10)]" ' send
a prompt out the serial port
MyData =DDERequest(Chan, "Field(1)") '
read back the response from Field(1)
Sheets("Sheet1").Cells(1, 1).Formula = MyData
' write the data to cell A1 in Sheet1
DDETerminate Chan 'terminate the DDE link
End Sub
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. |
