If you've never heard of Dynamic Data Exchange - a.k.a. DDE - consider yourself a lucky developer. In short, DDE is a simple communication protocol that allows two or more Windows processes to communicate with each other. DDE never really caught on, however a number of Microsoft applications and languages supported it, including of course Visual Basic (starting with version 3, if I remember correctly).

The main pros of DDE are its simplicity and flexibility: in most cases, you just need to set a few properties and you soon have a number of controls in a DDE client application reflect the state of a control in another application. More precisely, you can have a TextBox, Label, or PictureBox in an application (known as the DDE client) to be "linked" to a similar control in another application (known as the DDE server). You can even have multiple clients linked to the same server application, so that when the control in the server app changes, all the client apps automatically receive the new value. The DDE protocol allows other variations on this theme, for example the code in the client app can poke a value into a server's control, so that a client can indirectly notify all other clients that a new value is available.

DDE has several shortcomings, too, which explain why it never became very popular. For one, it appears to be quite fragile and you have no warranty that all the processes involved in the communication received the notification. For these reasons, it was soon replaced by COM in all developers' minds and hearths.

Regardless of what your opinion about DDE is, it's a fact that many VB6 applications - especially those that were born as VB3 projects - do rely on DDE. In the last few months we received several enqueries from potential customers who needed to migrate a VB6 app that was based on DDE to some extent. In these cases we could only suggest to replace DDE code with COM code before the migration, or replace portions of the VB.NET code with calls to native .NET technologies, such as remoting or WCF.

This is what all articles about migration recommend and is also what all our competitors do, but clearly wasn't what our customers liked to hear, especially because implementing a robust communication mechanism based on .NET requires time and skilled developers, plus the time required to fix the migrated VB.NET code to use the new mechanism.

About one month ago we rolled up our sleeves and we are now proud to announce the VB Migration Partner now supports all DDE properties, methods, and events!

Instead of implementing the "real" DDE protocol - an approach that would inherit all the DDE limitations and weaknesses - we decided to adopt a different approach based on Windows messages. This gives "our" DDE more robustness and better efficiency, while keeping it source-code-compatible with all existing DDE code written in VB6. In other words, we do support all the DDE properties and methods even if we internally use a different implementation.

Because of the approach we chosen, there are only a few minor differences with the "real" DDE protocol. The main limitation is that a migrated VB.NET app can use DDE only to communicate with another migrated VB.NET app. (If you used DDE to communicate with Microsoft Excel you can't use our prioprietary implementation, for example.) Also, our DDE protocol is inherently synchronous, therefore we don't support the LinkTimeout property and the LinkError event. Except for these details, the implementation is complete and sound. If your VB6 app uses DDE, this single feature can save you weeks during the migration process.

If you are interested in seeing a migrated VB.NET app that uses DDE, you can download a good sample here. The sample includes two projects - the client and the server - so you should launch the DDE server first and then one or more instances of the DDE client application. You will see that changing a field in the server app affects the linked control in all clients. You can compare the VB.NET behavior with the original VB6 application, whose source code are available here.

It almost goes without saying the VB Migration Partner is the FIRST and ONLY migration software that supports DDE, an achievement that confirms that our product is simply the state-of-the-art in its market segment.