VB Migration Partner

KNOWLEDGE BASE - Forms and controls


Previous | Index | Next 

[INFO] Minor differences between VB6 and VB.NET implementation of DDE

Starting with version 1.20, VB Migration Partner supports DDE-related properties, methods, and events. If you use Dynamic Data Exchange technology to have a VB6 communicate with another VB6 app, the two applications will work well together after the migration to VB.NET.

Internally, VB Migration Partner simulates DDE by means of inter-process Windows messages. Because of this implementation detail, there are a number of differences you should be aware of:

  1. DDE communications only work between migrated VB.NET apps; you can use DDE-related properties and methods to have a VB.NET application communicate with Microsoft Excel or another compiled Windows application.
  2. The LinkTimeout property is migrated, however it has no effect on converted VB.NET applications. Under VB.NET, a DDE communication can never time out.
  3. The LinkError event is migrated, however it is never triggered in the converted application.
  4. In current implementation, once a DDE communication is closed, you should avoid re-opening it by re-assigning a nonzero value to the LinkMode property of a client control.
  5. Use the VB6Config.DDEAppTitle property to change the application’s title used in DDE server apps.
  6. Because the DDE communication is simulated by means of Windows messages between a client control and a server form (in same or different application), please avoid changing any property of the control that might cause the control to be recreated, because this action would change the control’s handle and would break the connection.
  7. The LinkTopic property of forms isn't migrated, unless the LinkMode property is also set to the 1-Source at design time. If your VB6 form can immediately perform as a DDE source, you should set both the LinkTopic and LinkMode properties at design-time; however, if your VB6 form must execute some preliminary code before working as a DDE source, then you should set both the LinkTopic and LinkMode properties at runtime (e.g. in the Form_Load event). Setting the LinkTopic property at design time and the LinkMode property at runtime doesn’t work, because in this case VB Migration Partner won’t convert the former property.
  8. A form that an EnableAppFramework pragma selects as the application's splash form can’t work as a DDE source, else an InvalidOperationException "Cross-thread operation not valid" error occurs when the application is started.
  9. In VB6, closing a form that contains one or more controls that are engaged in a DDE communication fires one LinkClose event in each control and it also causes one LinkClose event to be fired for the form in the server application (more precisely, the form in the server application fires a number of LinkClose events that is equal to the number of controls in the client form for which a DDE communication is active). When a VB.NET form is closed, no LinkClose event is fired for the controls on the form being closed. Besides, the VB Migration Partner library doesn't guarantee that all LinkClose events in the server form are fired.
  10. If you set the LinkTopic property of a form to a non-empty string at design-time and leave the other properties unassigned, the form doesn’t behave well as an MDI child form (e.g. the Screen.ActiveForm property returns Nothing even if the form is selected). In this case you should assign the LinkTopic property at runtime, for example in the Form_Load event.
  11. The LinkSend method is exposed by the Label, TextBox, and PictureBox controls, however invoking this method on the Label and TextBox control raises an error 438 “Object doesn’t support this property or method” which is the VB6 behavior. You can avoid this error and have the LinkSend method work also for the TextBox and Label control by setting the VB6Config.DDEAllowLinkSend property to True.

More on last point: in some cases, Windows Forms controls are automatically recreated when you assign one or more “critical” properties. This happens, for example, when you change the value of the BorderStyle property of a TextBox control.

A good rule of thumb to understand whether a property is “critical” is looking at how the property is implemented under VB6. If the property is readonly at runtime, then odds are that the property forces the .NET Framework to recreate the control behind the scenes. Assignments to these properties should be avoided if the form or the control is involved in a DDE communication.

After assigning the LinkMode property to a nonzero value – an action that typically starts the DDE communication – it is therefore essential that you avoid modifying any property in the control other than Text (for TextBox controls), Caption (for Label controls), and Picture (for PictureBox controls). DDE-related properties – e.g. LinkTopic and LinkTimeout – can be safely used because they never force the control to be recreated.

Previous | Index | Next 




Follow Francesco Balena on VB6 migration’s group on

LinkedIn





Read Microsoft Corp’s official case study of a VB6 conversion using VB Migration Partner.




Code Architects and its partners offers remote and onsite migration services.

More details




Subscribe to our free newsletter for useful VB6 migration tips and techniques.

newsletter



To learn more about your VB6 applications, run VB6 Analyzer on your source code and send us the generated text file. You will receive a detailed report about your VB6 applications and how VB Migration Partner can help you to quickly and effectively migrate it to .NET.

Get free advice



A fully-working, time-limited Trial Edition of VB Migration Partner allows you to test it against your actual code

Get the Trial




The price of VB Migration Partner depends on the size of the VB6 application, the type of license, and other factors

Request a quote




Migrating a VB6 application in 10 easy steps

Comparing VB Migration Partner with Upgrade Wizard

Migration tools: Feature Comparison Table

All whitepapers