frmMain Form

frmMain Form

The application s primary form is frmMain. For multiple document interface (MDI) applications, it is an MDIForm; for single document interface (SDI) and Explorer applications, it is a standard form. Most of the modifications you have to complete for upgraded VB Application Wizard projects involve this form.

API Declare Statements

All projects generated by the VB Application Wizard contain an API Declare statement for OSWinHelp. MDI applications also contain a Declare statement for the SendMessage API. Here are the two Declare statements in Visual Basic 6:

Private Declare Function SendMessage Lib "user32" _ Alias "SendMessageA" _    (ByVal hwnd As Long, ByVal wMsg As Long, ByVal wParam As Long, _    ByVal lParam As Any) As Long Private Declare Function OSWinHelp% Lib "user32" Alias "WinHelpA" _    (ByVal hwnd&, ByVal HelpFile$, ByVal wCommand%, dwData As Any)

After upgrading, both of these Declare statements cause compile errors, since each of them passes variables as As Any. Here are the upgraded Declare statements:

Private Declare Function SendMessage Lib "user32"  Alias _    "SendMessageA"(ByVal hwnd As Integer, ByVal wMsg As Integer, _    ByVal wParam As Integer, ByVal lParam As Any) As Integer Private Declare Function OSWinHelp Lib "user32"  Alias "WinHelpA"( _    ByVal hwnd As Integer, ByVal HelpFile As String, _    ByVal wCommand As Short, ByRef dwData As Any) As Short

The SendMessage API is not used in VB Application Wizard projects, so you can simply remove the declaration for SendMessage. The As Any parameter for OSWinHelp should be changed to String, since it is used to pass the name of the Help file. After removing the SendMessage API and changing the OSWinHelp API, the declare statement for the API looks like this:

Private Declare Function OSWinHelp Lib "user32" Alias "WinHelpA" ( _    ByVal hwnd As Integer, ByVal HelpFile As String, _    ByVal wCommand As Short, ByRef dwData As String) As Short

	Although not discussed here, the correct Visual Basic .NET declaration for SendMessage is: Private Declare Function SendMessage Lib "user32" Alias _ "SendMessageA" (ByVal hwnd As Integer, _ ByVal wMsg As Integer, _ ByVal wParam As Integer, ByVal lParam As Integer) _ As Integer

mnuHelpAbout_Click Event Procedure

If you haven t added an About box to the application, the event for the About menu item, mnuHelpAbout_Click, has code that opens a message box with the application version:

MsgBox "Version " & App.Major & "." & App.Minor & "." & App.Revision

After upgrading, this code causes an error because it uses App.Revision to generate the application version. It upgrades to

MsgBox("Version " & _ System.Diagnostics.FileVersionInfo.GetVersionInfo( _ System.Reflection.Assembly.GetExecutingAssembly.Location _ ).FileMajorPart _ & "." & System.Diagnostics.FileVersionInfo.GetVersionInfo( _ System.Reflection.Assembly.GetExecutingAssembly.Location _ ).FileMinorPart & "." & App.Revision)

As we discussed in the section on App.Revision, you should replace this line with the following:

MsgBox("Version " & Application.ProductVersion)

App.HelpFile

App.HelpFile is used in several places in the frmMain form. Windows Forms has a new system for displaying Help that is not compatible with Visual Basic 6. Because of this incompatibility, the App.HelpFile property is not upgraded and causes a compile error after upgrading. If your application uses context-sensitive Help, you will have to reimplement it in Visual Basic .NET. If your application simply shows Help contents and a Help index, you can modify your application to show them. Simply replace the instances of App.HelpFile with the name of the Help file.

For example, in the mnuHelpSearchForHelpOn_Click event handler, the line

nRet = OSWinHelp(Me.hwnd, App.HelpFile, 261, 0)

is upgraded to

nRet = OSWinHelp(Me.Handle.ToInt32, App.HelpFile, 261, 0)

App.HelpFile generates a compile error. Suppose that your application s Help file is called C:\MyProject\MyProject.hlp. You would modify the line to read as follows:

nRet = OSWinHelp(Me.Handle.ToInt32, "c:\MyProject.hlp", 261, 0)

If your application doesn t contain a Help file, you can replace all instances of App.HelpFile with an empty string. For example, you would modify the line just shown to the following:

nRet = OSWinHelp(Me.Handle.ToInt32, "", 261, 0)

An easy way to make this change is to use the Find And Replace dialog box to replace all instances of App.HelpFile with , the empty string.

Implementing context-sensitive help in Visual Basic .NET applications is outside the scope of this book. If you want to learn more, search for the following topics in the Visual Basic .NET help: Help and User Assistance in Windows Applications and Introduction to the Windows Forms HelpProvider Control.

ActiveMdiChild in MDI Projects

In MDI applications, code in event procedures in the frmMain form, such as tbToolBar_ButtonClick, often uses soft binding to access controls on the active MDI child form. Visual Basic .NET detects and generates compile errors for controls that are accessed in this way.

Before discussing the solution, let s look a little closer at the reason that soft binding is used. When a user clicks a toolbar button or chooses a menu command from the MDI parent form, the code often acts upon the currently selected MDI child form. If an MDI application has many child forms, the active form is determined only at run time; therefore, it is common to use the ActiveForm object to access controls on the current form. For example, the following extract from the tbToolBar_ButtonClick event procedure shows how to change the text alignment of the selected text inside a control called rtfText on the active form:

Select Case Button.Key    Case "Align Right"       ActiveForm.rtfText.SelAlignment = rtfRight

For MDI applications, the Visual Basic .NET equivalent of Visual Basic 6 s ActiveForm is ActiveMdiForm. The code just shown upgrades to the following:

Select Case eventArgs.button.Key     Case "Align Right"       'UPGRADE_WARNING: Control rtfText could not be resolved because        'it was within the generic namespace ActiveMdiChild.       ActiveMdiChild.rtfText.SelAlignment = _        RichTextLib.SelAlignmentConstants.rtfRight

Notice that the Upgrade Wizard has inserted an EWI because it cannot resolve rtfText. Because the active form is defined dynamically at run time, the wizard has no way of knowing what control rtfText actually refers to. Visual Basic .NET has stronger type checking than Visual Basic 6, so it generates a compile error for this line of code. All the compiler knows is that ActiveMdiChild is a Form object, and rtfText is not a valid control or property of a standard Form object. To fix this error, you should either strongly type the form or force the code to use late binding. When possible, you should strongly type the form because doing so gives you IntelliSense and type checking at compile time. Here is how to modify the code to use strong type checking.

First of all, add a property called GetActiveMdiChild to the form:

ReadOnly Property GetActiveMdiChild() As frmDocument    Get       Return Me.ActiveMdiChild    End Get End Property

Then change all occurrences of ActiveMdiChild to use this property:

Select Case eventArgs.button.Key    Case "Align Right"       GetActiveMdiChild.rtfText.SelAlignment = _          RichTextLib.SelAlignmentConstants.rtfRight

Notice that since our property is of type frmDocument (the MDI child form), code can access properties, methods, and controls of the MDI child form. The compiler knows that rtfText is a control of frmDocument, so this code compiles and runs.

You will have to make this change for every procedure that uses controls of ActiveMdiChild. The easiest way to do this is to use the Find And Replace dialog box to replace all instances of ActiveMdiChild with GetActiveMdiChild . When you re doing the find and replace, be careful not to rename the newly added GetActiveMdiChild property.

What about MDI applications that have several different form types? What if the active child form could be one of a number of different forms? In most cases, the different child forms won t all have controls with the same name, but you can still fix the code to work. Defining GetActiveMdiChild as type Object will force the code to use late binding, and the control will be resolved only at run time. To do this, change the property to the following:

ReadOnly Property GetActiveMdiChild() As Object    Get       Return Me.ActiveMdiChild    End Get End Property

Where possible, however, you should avoid late binding and instead use the strongly typed version of the property. When the property is strongly typed, you get IntelliSense and type checking, and the code executes quicker.

Forms Collection in frmMain_Closed

In the Form_Unload event of SDI and Explorer applications, the VB Application Wizard generates code that unloads each open form:

'Close all sub forms For i = Forms.Count - 1 To 1 Step -1    Unload Forms(i) Next

This code upgrades to the following. Not shown here is that Form_Unload is renamed frmMain_Closed during the upgrade.

'Close all sub forms 'UPGRADE_ISSUE: Forms collection was not upgraded. 'UPGRADE_WARNING: Couldn't resolve default property of object Forms.Count. For i = Forms.Count - 1 To 1 Step -1    'UPGRADE_ISSUE: Forms collection was not upgraded.    'UPGRADE_ISSUE: Unload Forms(i) was not upgraded.    Unload(Forms(i)) Next

As we discussed in Chapter 15, the forms collection cannot be upgraded automatically. Fixing this problem is simple; you can remove this entire section of code, since Visual Basic .NET applications automatically unload all their child forms when the main form closes.

Clipboard in MDI Projects

MDI applications have three event procedures for the Clipboard object: Cut, Copy, and Paste. They are created as follows:

Private Sub mnuEditCut_Click()     On Error Resume Next     Clipboard.SetText ActiveForm.rtfText.SelRTF     ActiveForm.rtfText.SelText = vbNullString End Sub Private Sub mnuEditCopy_Click()     On Error Resume Next     Clipboard.SetText ActiveForm.rtfText.SelRTF End Sub Private Sub mnuEditPaste_Click()     On Error Resume Next     ActiveForm.rtfText.SelRTF = Clipboard.GetText End Sub

To make looking at the upgraded Clipboard code simpler, let s focus on the two lines of Clipboard code that set and get the Clipboard text, respectively:

Clipboard.SetText ActiveForm.rtfText.SelRTF ActiveForm.rtfText.SelRTF = Clipboard.GetText 

After the upgrade, these two lines cause errors in Visual Basic .NET, since the Clipboard object cannot be upgraded automatically (see Chapter 15).

'UPGRADE_ISSUE: Clipboard method Clipboard.SetText was not upgraded.        Clipboard.SetText(ActiveMdiChild.rtfText.SelRTF) 'UPGRADE_ISSUE: Clipboard method Clipboard.GetText was not upgraded. ActiveMdiChild.rtfText.SelRTF = Clipboard.GetText

You can fix the problem by adding two helper methods to Module1. These helper methods get and set the Clipboard text:

Function ClipboardSetText(ByVal newText As String)    Try       Clipboard.SetDataObject(newText, True)    Catch ex As Exception       MsgBox("Exception setting clipboard text: " & ex.Message)    End Try End Function Function ClipboardGetText()    Try       Dim sClipText As String       Dim stringData As IDataObject       Dim getString As New DataObject(DataFormats.StringFormat)       stringData = Clipboard.GetDataObject()       If stringData.GetDataPresent(DataFormats.Text) Then          sClipText = stringData.GetData(DataFormats.Text, True)          Return sClipText       End If    Catch ex As Exception       MsgBox("Exception getting clipboard text: " & ex.Message)    End Try End Function

Now you just need to modify the set and get code to call these functions:

ClipboardSetText(GetActiveMdiChild.rtfText.SelRTF) GetActiveMdiChild.rtfText.SelRTF = ClipboardGetText()

Notice that we ve also changed ActiveMdiChild to GetActiveMdiChild, as we recommended earlier.