Seeing POKE, but no data arriving....

Jul 10, 2008 at 12:35 PM
We have a COTS application (to which we have no debug access) which is using DDE POKE to send data to our VB6 Application.  As VB6 is going out of support we are upgarding to VB.NET.  To replace the native DDE functions of VB, we are looking at NDDE.  Currently we have the situation where our VB.NET application receives a POKE message but the data is not being transmitted.  Has anyone else experienced this ?  Is this a similar issue to http://www.codeplex.com/ndde/Thread/View.aspx?ThreadId=23553?

Thanks in advance

    Ben
Coordinator
Jul 10, 2008 at 7:18 PM


BenTaylorUK wrote:
We have a COTS application (to which we have no debug access) which is using DDE POKE to send data to our VB6 Application.  As VB6 is going out of support we are upgarding to VB.NET.  To replace the native DDE functions of VB, we are looking at NDDE.  Currently we have the situation where our VB.NET application receives a POKE message but the data is not being transmitted.  Has anyone else experienced this ?  Is this a similar issue to http://www.codeplex.com/ndde/Thread/View.aspx?ThreadId=23553?

Thanks in advance

    Ben


Hi Ben.  Are you getting an exception when calling the DdeClient.Poke method?  If so can you post the message and stack trace here. 

One important thing to remember is to set the format parameter correctly.  Most DDE servers accept the CF_TEXT (int value of 1), but not all.  Try setting that format parameter to a value of 1.  Most other formats are proprietary so I cannot offer any assistance if your DDE server does not respond to that.
Jul 10, 2008 at 8:05 PM
Thanks for the reply Brian.  Unfortunately the app calling Poke (which I'll call the Client) is an "commercial off the shelf package" which we can't see the internal workings of and hence we have no idea if it is getting an exception, but it is not showing any sign of failures. 

The Client has been seen to poke a VB6 based 'Server' successfully (and has done so for many years); we are now trying to get it to work with VB.NET. 

The POKE message is received by our .NET NDDE based Server, but the data is not received.  Any thoughts?
Coordinator
Jul 16, 2008 at 1:16 AM


BenTaylorUK wrote:
Thanks for the reply Brian.  Unfortunately the app calling Poke (which I'll call the Client) is an "commercial off the shelf package" which we can't see the internal workings of and hence we have no idea if it is getting an exception, but it is not showing any sign of failures. 

The Client has been seen to poke a VB6 based 'Server' successfully (and has done so for many years); we are now trying to get it to work with VB.NET. 

The POKE message is received by our .NET NDDE based Server, but the data is not received.  Any thoughts?


I apologize for the late response.  Okay, so you're writting the DDE server end.  I didn't realize that before.

The good news is that you're receiving the POKE message.  That eliminates a lot of problems.  The bad news is that you're not getting the data.  This could be very problematic.  One question, what makes you think you're not receiving any data?

You may have to step through the code in NDDE to see what's happening.  If you're willing to do that you'll want to set a breakpoint in the DdemlServer.ProcessCallback method where it is processing the XTYP_POKE transaction.  It's unlikely that there is a bug in NDDE at this point, but anything is possible.  One thing that could be happening is that the client is not complying with the DDE protocol, but VB6 is smart enough to compensate whereas NDDE is not.  I have see cases of this in the past.
Jul 17, 2008 at 12:44 PM


briangideon wrote:
I apologize for the late response.  Okay, so you're writting the DDE server end.  I didn't realize that before.

The good news is that you're receiving the POKE message.  That eliminates a lot of problems.  The bad news is that you're not getting the data.  This could be very problematic.  One question, what makes you think you're not receiving any data?

You may have to step through the code in NDDE to see what's happening.  If you're willing to do that you'll want to set a breakpoint in the DdemlServer.ProcessCallback method where it is processing the XTYP_POKE transaction.  It's unlikely that there is a bug in NDDE at this point, but anything is possible.  One thing that could be happening is that the client is not complying with the DDE protocol, but VB6 is smart enough to compensate whereas NDDE is not.  I have see cases of this in the past.

Thanks for you advice Brian.  We will look into that and report back.