This Visual Basic Today column builds on the previous column, “Write an FTP Client with VB.NET to Bridge Legacy Software,” which introduced an FTP client with some basic FTP capabilities. It extends that FTP client and begins the implementation of a Windows FTP GUI. I could probably write an entire book on building a Windows FTP application if I elected to cover design, implementation, patterns, GUI design techniques, and testing and deployment issues. However, I don’t have that much time or enough space in this forum.
This column presents an assortment of skills you might need to complete the Windows FTP solution or similar kinds of applications. It further explores the TcpClient namespace and using new controls in Visual Studio .NET 2005. It also demonstrates a couple of patterns that you should know. Although the example it presents is implemented with VS.NET 2005, you could implement it in VS.NET 2003 with simple control substitutions.
Add Get File List to Your FTP Client
Client is one of those words that can be a bit ambiguous. Client can be code that talks to a server, but it also can mean GUI. (A less ambiguous term for GUI client is presentation layer.) This section refers to the client code and not a GUI.
“Write an FTP Client with VB.NET to Bridge Legacy Software” began the process of building an FTP client application. It implemented that client as a class library that could be used from any sort of application. Despite being 15 pages long in my word processor, that article still wasn’t long enough to cover implementing all of the commands FTP servers support as defined by RFC (Request For Comment) 959. To make your presentation layer more interesting, implement another command, NLST, which returns a list of files on the FTP server.
To implement NLST, you need to add three more methods to your FtpClient:
- GetFileList—directly implements the NLST command
- CreateDataSocket—implements the PASV command and creates a second data socket (The PASV command tells the server to wait for a client to connect to it on a port the server designated.)
- RequestResponse—returns the actual data that is returned from the server
RequestResponse is useful when you want to retrieve data like a list of files as opposed to server code. Listing 1 shows the implementation of GetFileList, CreateDataSocket, and RequestResponse.
Listing 1: GetFileList, CreateDataSocket, and RequestResponse (to be added to the FtpClient class)
Public Function GetFileList(ByVal mask As String) As String() Const BUFFER_SIZE As Integer = 512 Dim buffer(BUFFER_SIZE) As Byte Dim socket As Socket = Nothing Dim bytes As Integer Const separator As Char = "n" Dim messageChunks As String() Dim temp As String = "" ' Implement this socket = CreateDataSocket() Try SendCommand("NLST " + mask) While (True) Array.Clear(buffer, 0, buffer.Length) bytes = socket.Receive(buffer, buffer.Length, 0) temp += ASCII.GetString(buffer, 0, bytes) If (bytes < buffer.Length) Then Exit While End While messageChunks = temp.Split(separator) Finally socket.Close() End Try Return messageChunks End Function Private Function CreateDataSocket() As Socket Dim index1, index2, len, port, partCount As Integer Dim ipData, buf, ipAddress As String Dim parts(6) As Integer Dim ch As Char Dim socket As Socket Dim ep As IPEndPoint Dim reply As String = RequestResponse("PASV") index1 = reply.IndexOf("(") index2 = reply.IndexOf(")") ipData = reply.Substring(index1 + 1, index2 - index1 - 1) len = ipData.Length partCount = 0 buf = "" Dim I As Integer = 0 While (I <= len - 1 And partCount <= 6) ch = Char.Parse(ipData.Substring(I, 1)) If (Char.IsDigit(ch)) Then buf += ch ElseIf (ch <> ",") Then Throw New IOException("Malformed PASV reply: " + _ reply) End If If ((ch = ",") Or (I + 1 = len)) Then Try parts(partCount) = Int32.Parse(buf) partCount += 1 buf = "" Catch Throw New IOException("Malformed PASV reply: " _ + reply) End Try End If I += 1 End While ipAddress = String.Format("{0}.{1}.{2}.{3}", parts(0), _ parts(1), parts(2), parts(3)) port = parts(4) << 8 port = port + parts(5) socket = New Socket(AddressFamily.InterNetwork, _ SocketType.Stream, ProtocolType.Tcp) ep = New IPEndPoint(Dns.Resolve(ipAddress).AddressList(0), _ port) Try socket.Connect(ep) Catch ex As Exception Throw New IOException("Cannot connect to remote _ server", ex) End Try Return socket End Function Private Function RequestResponse(ByVal command As String) As String command += Environment.NewLine Dim commandBytes() As Byte = ASCII.GetBytes(command) clientSocket.Send(commandBytes, commandBytes.Length, 0) Return ReadLine() End Function
I borrowed these methods from the Microsoft article “How to access a File Transfer Protocol Site by Using Visual Basic .NET,” originally published as knowledge base article 832679 from Microsoft.com. They are a bit murkier than I like. Code like this often needs some careful refactoring and a couple of attempts in order to “prettify” it, but in this case, that would be a distraction with only cosmetic returns. (For more information on refactoring, refer to Martin Fowler’s book, Refactoring: Improving the Design of Existing Code.)
If you want to learn more about FTP commands, refer to the supported and unsupported FTP commands on the Microsoft.com Web site. If you want to learn more about FTP status codes, refer to knowledge base article Q318380, “IIS Status Codes.”
Implement an FTP GUI
Having added the GetFileList, CreateDataSocket, and RequestResponse methods to your FtpClient class (see “Write an FTP Client with VB.NET to Bridge Legacy Software” for the complete listing of the FtpClient), you can now design a presentation layer around the Connect, Login, Disconnect, and GetFileList capabilities of your FtpClient class. You then add a VS.NET 2005 menu, status control, and a user control that can display the files returned from the server.
Add a MenuStrip to the Form
The next version of VS.NET replaces the MenuBar with a MenuStrip. The basic functionality is the same, but I find using the MenuStrip a bit clumsier. For example, to add a separator to menus in previous versions of VB, one only had to use the hyphen (-) as the text for the MenuItem. This was exceptionally easy. Whidbey (VS.NET 2005) objectifies as a ToolStripSeparator the indented line that separates regions of a menu. Instead of using a hyphen to create the separator, one needs to right-click over the menu in design mode and select Edit DropDownItems… from the context menu (see Figure 1).
Figure 1: Modifying Menus Is a Bit More Confusing in Whidbey
Selecting the Edit DropDownItems menu opens an Items Collection Editor (see Figure 2) where you can have more precise manipulation of MenuStrip elements. (Beta software is subject to change, so hopefully Microsoft will simplify the MenuStrip behavior.)
Figure 2: Adding a Separator Requires Use and Knowledge of the Items Collection Editor.
MenuStrip behavior—once the menu is created—is similar to MenuBar behavior. Define the StripMenuItem and double-click to generate an event handler. For this article, I added File, View, and Help StripMenuItems. File supports connecting, disconnecting, and exiting. View supports requesting a remote files list, and Help has an About sub-item. For each of these menu items, I created an event handler in the usual way and invoked the related capabilities.
File|Connect invokes the FtpClient.Connect and FtpClient.Login behaviors. File|Disconnect invokes the FtpClient.Disconnect behavior. View|Get Remote Files invokes the FtpClient.GetFileList behavior, and Help|About uses MessageBox.Show (MsgBox) behavior to display a simple About dialog box.
The Form_Load method is used to create an instance of the FtpClient object and a FileListUserControl dynamically. (Find the complete listing for the form at the end of this article.) Whidbey presently separates designer-generated code from user-generated code. It will add designer-generated code to a file named filename.Designer.vb. For example, if you have a form named Form1, Whidbey will create Form1.vb, Form1.Designer.vb, and Form1.resx. Generally, you will add your code to Form1.vb in this scenario.
Create a File List User Control
To support listing files on the client and server, you can implement one user control and ultimately use it twice: once for the client-side files and once for the server-side files. In this example, you instantiate one user control for server-side files.
The FileListUserControl is comprised of a Label, a Panel with a Button and ComboBox, and a TreeView. You use the Label to indicate what the control contains. You can ultimately use the Button and ComboBox to change folders or drives where applicable and the TreeView to display the files discovered on the client or the server. For practical purposes, you can surface the Text value of the Label to permit consumers to change it, and hide the ComboBox when the FileListControl represents the remote server and show it when the FileListUserControl represents the client. Figure 3 shows the design-time view of the FileListUserControl.
Figure 3: The FileListUserControl Is a Generic User Control That Accepts a String Array But Is Generally Unaware of the Origin or Meaning of the Data.
The FileListUserControl is straightforward: Pass an array of strings and the SetFiles method calls an Add method for each string in the array, adding the string to the TreeView control. Listing 2 contains the code for the FileListUserControl. (The designer-generated code is contained in a file named *.designer.vb in Whidbey.)
Listing 2: The Implementation of the FileListUserControl
Imports System Imports System.Collections Imports System.ComponentModel Imports System.Drawing Imports System.Data Imports System.IO Imports System.Windows.Forms Public Class FileListUserControl Public Property Caption() As String Get Return Label1.Text End Get Set(ByVal value As String) Label1.Text = value End Set End Property Public Sub SetFiles(ByVal files() As String) treeViewFiles.Nodes.Clear() Add(".") Add("..") Dim file As String For Each file In files If (file.Trim() <> String.Empty) Then Add(file.Trim()) End If Next End Sub Private Sub Add(ByVal file As String) Broadcaster.Broadcast(String.Format("Adding {0}", file)) treeViewFiles.Nodes.Add(New TreeNode(file)) End Sub Private Sub FileListUserControl_Resize(ByVal sender _ As System.Object, _ ByVal e As System.EventArgs) Handles MyBase.Resize treeViewFiles.SetBounds(0, 80, Width, Height - 80) Label1.SetBounds(0, 0, Width, 40) Panel1.SetBounds(0, 40, Width, 40) End Sub End Class
Attach the FTP Client to the GUI
Next, you need to attach the FtpClient class library to your GUI. You can accomplish this easily from an architectural perspective by using the Observer pattern. From a practical point of view, the Observer pattern is manifested as events.
To attach the FtpClient to the GUI, declare and create an instance of the FtpClient and then define and attach event handlers to the FtpClient using the AddHandler statement. The code that demonstrates how to manually add event handlers is shown in the Form1_Load event handler in Listing 3 and in context in the Form’s code listing at the end of this article.
Listing 3: The Form1_Load Method Demonstrates How to Manually Attach Event Handlers.
Private ftp As FtpClient = Nothing Private FileControl As FileListUserControl Private Sub Form1_Load(ByVal sender As System.Object, _ ByVal e As System.EventArgs) Handles MyBase.Load Broadcaster.Add(Me) ftp = New FtpClient("localhost", ".", "anonymous", _ "pkimmel@softconcepts.com", 21) AddHandler ftp.OnTcpEvent, AddressOf OnTcpEvent FileControl = New FileListUserControl FileControl.Caption = "Remote Files" FileControl.Parent = Panel1 Panel1.Controls.Add(FileControl) FileControl.Dock = DockStyle.Fill End Sub
(Rather than remove the code for the FileListUserControl, I show the code for dynamically creating the UserControl in Listing 3 too.) The AddHandler statement requires an object and its event field, and the second parameter is the AddressOf the event handler. Implicitly, AddressOf creates an instance of a delegate object, which is a class that encapsulates event handlers.
Update a StatusStrip
Whidbey has replaced the StatusBar with the StatusStrip. Although it is a little more clumsy to use than the StatusBar, it is more OOPy but will feel a tad foreign. Basically, the StatusStrip is a status bar that has more advanced designers similar to the MenuStrip’s designers. Instead of repeating that information here, let’s talk about a proper way to update status information on your presentation layer.
Status information could literally come from anywhere. The FtpClient’s state will change, and you might elect to report that status information. The FileListUserControl’s or Form1’s status might change, and you might elect to report that status information. Obviously, you could define a method in the Form that permits updating status, but then every status reporting object would need to have an instance of the Form. That would be a spaghetti code nightmare. If you asked yourself why, consider an example using just one reporting object, the Form. Suppose the FtpClient is told about the main form in the Windows client. This means the Windows client must have a reference to the FtpClient to invoke behaviors and the FtpClient must have a reference to the Windows Form to update status. In addition to being a circular reference, the FtpClient class also breaks if Form1 goes away, and you can’t reuse the FtpClient in some other application without dragging the Windows Forms client along with it. This is called tightly coupled code and it is a bad thing.
A better alternative would be to define an OnStatusChange method in the FtpClient, attach the Windows Form to that event, and raise the event when status changes. While this represents looser coupling and better cohesion, it still means that other status-reporting objects would need to follow suit with events and event handlers.
The best solution can be had by again using the Observer pattern. However, in this context, think of the Observer pattern by its alter ego publish-subscribe or what I call broadcaster and listeners. (Think radio station and radio listeners.) Defining a broadcaster and listener means that you can broadcast status messages (from anywhere) and any listener can tune it. By combining the Singleton (to ensure one instance of the broadcaster) and the Observer patterns, you can send status messages from anywhere without any knowledge of who or what is listening. (If you need some validation for this solution, keep in mind that it is precisely how Microsoft implemented the System.Diagnostics.Trace class and TraceListeners to send Trace information to the Output window in VS.NET itself.)
Implement the Listener
Listening is comprised of two parts: an interface named IListener and a typed collection of IListeners. Using an interface means that any class that implements IListener can tune in to broadcasts. You might think inheritance would work here, but remember an obvious listener is a Form and it already inherits from the System.Windows.Forms.Form and multiple inheritance is not allowed in VB.NET.
Next, your broadcaster may want to multicast. Thus, you need a means of knowing about multiple listeners; for example, you might want to log status messages in the EventLog. Such a scenario is ideally suited for a strongly typed collection of IListeners. Listing 4 shows both the IListener and ListenerCollection. (For more information about typed collections, read my book Visual Basic .NET Power Coding from Addison-Wesley, and for more information about the Observer pattern, refer to Design Patterns by Erich Gamma, et. al., also from Addison-Wesley.)
Listing 4: The IListener and ListenerCollection Classes
Public Interface IListener ReadOnly Property Listening() As Boolean Sub Listen(ByVal message As String) End Interface Imports System Imports System.Collections Public Class ListenerCollection Inherits CollectionBase Default Public Property Item(ByVal index As Integer) As IListener Get Return CType(List(index), IListener) End Get Set(ByVal value As IListener) List(index) = value End Set End Property Public Function Add(ByVal value As IListener) As Integer Return List.Add(value) End Function Public Sub Remove(ByVal value As IListener) Dim I As Integer For I = 0 To List.Count - 1 If (Item(I) Is value) Then List.RemoveAt(I) Exit For End If Next End Sub End Class
Whidbey also has added a new project item template for interfaces (see Figure 4).
Figure 4: Whidbey Supports Several More Template Items, Generating More Code for You.
Implementing the Broadcaster
The Broadcaster class uses the Singleton pattern to ensure only one Broadcaster exists. You typically implement the Singleton pattern by making the constructor non-public and using a Shared method to request an instance of the class, which is created only once. Also, the Broadcaster contains Add and Remove methods that add and remove IListeners from an internal ListenerCollection held by the Broadcaster. Listing 5 provides the implementation of the Broadcaster class.
Listing 5: The Broadcaster Piece of Your Solution Plays the Role of Subject in the Observer Pattern.
Public Class Broadcaster Private listeners As ListenerCollection = Nothing Private Shared FInstance As Broadcaster = Nothing Protected Sub New() listeners = New ListenerCollection End Sub Public Shared Sub Add(ByVal value As IListener) Instance.listeners.Add(value) End Sub Public Shared Sub Remove(ByVal value As IListener) Instance.listeners.Remove(value) End Sub Public Shared Sub Broadcast(ByVal message As String) Dim listener As IListener For Each listener In Instance.listeners If (listener.Listening) Then listener.Listen(message) End If Next End Sub Protected Shared ReadOnly Property Instance() As Broadcaster Get If (FInstance Is Nothing) Then FInstance = New Broadcaster End If Return FInstance End Get End Property End Class
All that remains is referring to the assembly that contains the broadcaster and listener and beginning broadcasting and listening. To Broadcast information, call Broadcaster.Broadcast. To Listen, reference the assembly containing the Broadcaster and Listener, realize the IListener interface, and register as a listener with the Broadcaster. The Form code in Listing 6 demonstrates the mechanics of the Broadcaster and IListener in practice.
Reference: Form Code Listing
Listing 6 contains the complete listing for the form for your Windows FTP GUI. Keep in mind that generated code is placed in a *.Designer.vb file in Whidbey.
Listing 6: The Form Code for the GUI
Imports Ftp Public Class Form1 Implements IListener Private ftp As FtpClient = Nothing Private FileControl As FileListUserControl Private Sub Form1_Load(ByVal sender As System.Object, _ ByVal e As System.EventArgs) Handles MyBase.Load Broadcaster.Add(Me) ftp = New FtpClient("localhost", ".", "anonymous", _ "pkimmel@softconcepts.com", 21) AddHandler ftp.OnTcpEvent, AddressOf OnTcpEvent FileControl = New FileListUserControl FileControl.Caption = "Remote Files" FileControl.Parent = Panel1 Panel1.Controls.Add(FileControl) FileControl.Dock = DockStyle.Fill End Sub Public Sub Listen(ByVal message As String) Implements _ IListener.Listen UpdateStatus(message) End Sub Private Sub UpdateStatus(ByVal message As String) StatusStripPanel1.Text = message End Sub Public ReadOnly Property Listening() As Boolean _ Implements IListener.Listening Get Return True End Get End Property Private Sub AboutToolStripMenuItem_Click(ByVal sender _ As System.Object, ByVal e As System.EventArgs) _ Handles AboutToolStripMenuItem.Click Dim About As String = _ "WinFTP Client" + Environment.NewLine + _ "Copyright (c) 2004. All Rights Reserved." + _ Environment.NewLine + "pkimmel@softconcepts.com" MessageBox.Show(About, "About WinFTP", _ MessageBoxButtons.OK, _ MessageBoxIcon.Information) End Sub Private Sub GetRemoteFilesToolStripMenuItem_Click(ByVal sender _ As System.Object, ByVal e As System.EventArgs) _ Handles GetRemoteFilesToolStripMenuItem.Click FileControl.SetFiles(ftp.GetFileList("*.*")) End Sub Private Sub ConnectToolStripMenuItem_Click(ByVal sender _ As System.Object, ByVal e As System.EventArgs) _ Handles ConnectToolStripMenuItem.Click ftp.Connect() ftp.Login() End Sub Private Sub DisconnectToolStripMenuItem_Click(ByVal sender _ As System.Object, ByVal e As System.EventArgs) _ Handles DisconnectToolStripMenuItem.Click ftp.Disconnect() End Sub Private Sub ExitToolStripMenuItem_Click(ByVal sender _ As System.Object, ByVal e As System.EventArgs) _ Handles ExitToolStripMenuItem.Click Close() End Sub Private Sub OnTcpEvent(ByVal sender As Object, ByVal e _ As TcpEventArgs) UpdateStatus(e.Data) End Sub Private Sub FileToolStripMenuItem_Click(ByVal sender _ As System.Object, ByVal e As System.EventArgs) _ Handles FileToolStripMenuItem.Click End Sub End Class
The Elements for a Complete Solution
Writing software is hard. Writing good software is especially difficult, and great software is exceedingly rare. However, great software has some common elements and one of these is the use of well-known patterns in its design and implementation.
This article has demonstrated several kinds of skills you might need to write good software. Although a complete solution would not fit in an article, what you have here are the elements that you need to implement a whole solution. For example, you used the Observer and Singleton patterns, as well as delegates (a.k.a., events) to decouple the FtpClient from any particular GUI. You extended your FtpClient a bit more and got a chance to explore some of the new controls in Whidbey. (Keep in mind that Whidbey is beta software and is subject to change.)
Biography
Paul Kimmel, the VB Today columnist, is a software architect who has written several books on .NET programming. Look for more information on patterns and software design in his upcoming book UML DeMystified from McGraw-Hill/Osborne (Spring 2005). You may contact him at pkimmel@softconcepts.com if you need assistance developing software or are interested in joining the Lansing Area .NET Users Group (glugnet.org).
Copyright © 2004 by Paul Kimmel. All Rights Reserved.