0

Put on your wayback hats...

I have to use DDE (sorry, absolutely no choice in this) to communicate with an industrial control system. The control system is the DDE server and runs on the same Windows 7 PC as my DDE client. The client uses MfcDDE as it's interface which in turn makes calls to the DdeClientTransaction() functions.

The DDE advise operations work as expected after calling MfcDDE to establish them with DdeClientTransaction(XTYP_ADVSTART). All data points of interest are successfully read through the advice mechanism.

Unfortunately, attempts to write data through the DdeClientTransaction(XTYP_POKE) function fails. Within my client, DdeGetLastError() returns DMLERR_INVALIDPARAMETER (16390 0x4006). Interestingly, DDESpy (yes, I am that desparate) is reporting DMLERR_POSTMSG_FAILED (16396 0x400C).

The client worked in its initial NT implementation, but rebuilt and running under Win7, the XTYPE_POKE is failing. I've contemplated both security and threading as possibilities.

I've been unsuccessful finding a pointing gun for DDE security changes between NT and Win7.

If it matters, the DdeClientTransaction() call is being made in a thread started with WinMain() calling through to AfxWinMain() and CDialog::DoModal() to get to client's functional code.

Thanks for any help you can provide...

Anonymous
  • 11,740
  • 3
  • 40
  • 50
  • FWIW: I wrote as if MfcDDE was a commonly known thing. For the record, it is a relatively lightweight set of MFC classes to use DDE written by Julian Smart. – Steve Rosenberry Jun 25 '16 at 19:10
  • I found a sample DDE program, built it, and was able to poke values. That seems to rule out any security issues. I then used the code it uses in my client. It makes a calls to DdeCreateStringHandle() which also gets the DMLERR_INVALIDPARAMETER failure. I'm thinking possibly ANSI vs. UNICODE. My client is built as ANSI. – Steve Rosenberry Jun 25 '16 at 20:24
  • While the call to DdeClientTransaction(XTYP_POKE) was made on a thread with a message queue; it was not being made on the same thread that initially called DdeInitialize(). I suspect that is going to be the issue and am in the process of confirming... – Steve Rosenberry Jun 25 '16 at 21:11

1 Answers1

0

Confirmed that DdeClientTransaction(XTYP_POKE) can only be called on the same thread upon which DdeInitialize() was called. The restriction may actually be the same thread upon which DdeConnect() was called, but my money is on the DdeInitialize() since the returned DDEIdInst is passed to DdeConnect(). I could be wrong.

Thanks for letting me work through this with you guys... :)